國產數據庫的兼容性突圍:金倉KingbaseES深度實測,用戶變量與事件調度器表現驚艷!
個人簡介
作者: ShunWah
公眾號: “順華星辰運維棧”主理人。持有認證: OceanBase OBCA/OBCP、MySQL OCP、OpenGauss、崖山 DBCA、亞信 AntDBCA、翰高 HDCA、GBase 8a | 8c | 8s、Galaxybase GBCA、Neo4j Graph Data Science Certification、NebulaGraph NGCI & NGCP、東方通 TongTech TCPE 等多項權威認證。
獲獎經歷: 在OceanBase&墨天輪征文大賽、OpenGauss、TiDB、YashanDB、Kingbase、KWDB 征文等賽事中多次斬獲一、二、三等獎,原創技術文章常年被墨天輪、CSDN、ITPUB 等平臺首頁推薦。
- 公眾號:順華星辰運維棧
- CSDN:shunwahma
- 墨天輪:shunwah
- ITPUB:shunwah

一、 引子:擁抱國產化浪潮,體驗平替先鋒
“2025金倉數據庫產品體驗官火熱招募”的號角已然吹響,“數據庫平替用金倉”的理念正席卷技術圈!作為國產數據庫的領軍力量,金倉數據庫(KingbaseES)以其卓越的性能、高度的兼容性和完善的企業級特性,正成為眾多關鍵業務系統從傳統數據庫(如 MySQL、Oracle)平滑遷移、安全可控的理想選擇。本次“MySQL 兼容深度體驗”第2期聚焦實戰測評,我有幸作為體驗官,將深入金倉數據庫 V9 版本,圍繞其核心的 PLMYSQL 兼容特性——特別是對 MySQL 用戶變量和事件調度器 (Event Scheduler) 的支持,進行從零開始的構建與深度測試,一探其兼容實力。
二、 體驗環境準備
1、數據庫環境準備
- 數據庫版本: 金倉數據庫管理系統 KingbaseES V9 (為本次體驗專門部署的測試環境)
- MySQL 兼容版部署可參考鏈接 【金倉數據庫產品體驗官】從零實測:金倉數據庫MySQL兼容深度探秘

2、確認數據庫類型和版本:
ecommerce_db=# SELECT version();
version
-------------------------
KingbaseES V009R003C011
(1 row)

3、檢查已安裝的擴展:
ecommerce_db=# SELECT * FROM pg_extension;
oid | extname | extowner | extnamespace | extrelocatable | extversion | extconfig | extcondition
-------+-----------------------+----------+--------------+----------------+------------+-----------+-------------
13276 | plpgsql | 10 | 11 | f | 1.0 | |
13278 | kdb_license | 10 | 11 | f | 1.1 | |
13280 | sysaudit | 10 | 13279 | f | 1.0 | |
13286 | src_restrict | 10 | 13285 | f | 1.0 | |
13289 | sysmac | 10 | 13288 | f | 1.0 | |
13297 | sys_anon | 10 | 13296 | f | 1.0 | |
13299 | sys_hm | 10 | 11 | f | 1.0 | |
13305 | kingbase_version | 10 | 11 | f | 1.1 | |
13541 | kdb_charbyte | 10 | 8000 | f | 1.0 | |
13840 | kdb_inherit_functions | 10 | 8000 | f | 1.5 | |
13860 | kdb_mysql_datatype | 10 | 11 | f | 1.7 | |
12125 | plmysql | 10 | 11 | f | 1.0 | |
12126 | kdb_mysql_functions | 10 | 8000 | t | 1.15 | |
12129 | kdb_cast | 10 | 8000 | f | 1.0 | |
12218 | sys_freespacemap | 10 | 8000 | t | 1.3 | |
12519 | xlog_record_read | 10 | 11 | t | 1.0 | |
12521 | sys_stat_statements | 10 | 2200 | t | 1.11 | |
12530 | kdb_tinyint | 10 | 11 | f | 1.0 | |
(18 rows)

三、 實戰第一步:構建基礎——庫與表的創建
兼容性的基石在于最基礎的 DDL 操作。我們首先模擬一個典型的 MySQL 應用場景——創建一個電商相關的數據庫和表。
1. 創建數據庫
使用熟悉的 CREATE DATABASE 語法。
[kingbase@worker3 ~]$ ksql -U system -d test -p 54321
Password for user system:
Licesen Type: SALES-企業版.
Type "help" for help.
test=# CREATE DATABASE ecommerce_db WITH ENCODING = 'UTF8';
CREATE DATABASE
test=# \c ecommerce_db;
You are now connected to database "ecommerce_db" as userName "system".
ecommerce_db=#

執行順暢,語法與 MySQL 完全兼容。
2. 創建核心業務表
創建一個 orders (訂單表) 和一個 audit_log (審計日志表,用于后續事件調度器演示)。
2.1 創建訂單表 (orders):
ecommerce_db=# CREATE TABLE orders (
ecommerce_db(# order_id SERIAL PRIMARY KEY,
ecommerce_db(# customer_id INT NOT NULL,
ecommerce_db(# order_date TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
ecommerce_db(# total_amount DECIMAL(10, 2) NOT NULL,
ecommerce_db(# status VARCHAR(20) NOT NULL DEFAULT 'NEW'
ecommerce_db(# );
CREATE TABLE

2.2 創建審計日志表 (audit_log):
ecommerce_db=# CREATE TABLE audit_log (
ecommerce_db(# log_id SERIAL PRIMARY KEY,
ecommerce_db(# action VARCHAR(50) NOT NULL, -- 操作類型 (e.g., 'Order_Created', 'Status_Updated')
ecommerce_db(# target_table VARCHAR(50) NOT NULL, -- 操作的目標表
ecommerce_db(# target_id INT, -- 操作記錄的主鍵ID (如 order_id)
ecommerce_db(# action_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
ecommerce_db(# performed_by VARCHAR(50) DEFAULT CURRENT_USER -- 執行操作的用戶
ecommerce_db(# );
CREATE TABLE

表結構定義語法與 MySQL 高度一致。特別留意 SERIAL 類型,它在金倉 MySQL 兼容模式下完全模擬了 MySQL AUTO_INCREMENT 的行為。DEFAULT CURRENT_TIMESTAMP 和 DEFAULT CURRENT_USER 等默認值表達式也完美支持。
3. 插入測試數據
3.1 插入一些訂單數據:
ecommerce_db=# INSERT INTO orders (customer_id, total_amount, status) VALUES
ecommerce_db-# (1001, 199.99, 'NEW'),
ecommerce_db-# (1002, 349.50, 'PROCESSING'),
ecommerce_db-# (1003, 55.00, 'COMPLETED'),
ecommerce_db-# (1001, 78.90, 'NEW');
INSERT 0 4

3.2 插入一條審計日志示例:
ecommerce_db=# INSERT INTO audit_log (action, target_table, target_id) VALUES ('Initial_Setup', 'orders', NULL);
INSERT 0 1

數據插入語法、VALUES 列表格式與 MySQL 無異,操作流暢。
四、 核心兼容特性深度測評:PLMYSQL 閃耀時刻
(一) MySQL 用戶變量 (@varname) 兼容性測試
用戶變量是 MySQL 中非常靈活的特性,用于在會話內存儲臨時值,常用于存儲查詢中間結果、跨語句傳遞數據或在存儲過程中簡化邏輯。金倉 PLMYSQL 對此提供了優秀的兼容。
測試場景 1:基礎賦值與使用
1.1 – 設置用戶變量
SET @customer_id := 1001; -- 使用 := 賦值 (兼容 MySQL 的 SET 語法)
SET @discount_rate = 0.9; -- 使用 = 賦值 (也是兼容的)
ecommerce_db=# SET @customer_id := 1001;
SET
ecommerce_db=# SET @discount_rate = 0.9;
SET

1.2 在查詢中使用用戶變量:
ecommerce_db=# SELECT * FROM orders WHERE customer_id = @customer_id;
order_id | customer_id | order_date | total_amount | status
----------+-------------+---------------------+--------------+--------
1 | 1001 | 2025-08-13 15:01:40 | 199.99 | NEW
4 | 1001 | 2025-08-13 15:01:40 | 78.90 | NEW
(2 rows)

1.3 計算并存儲新值:
ecommerce_db=# SELECT @max_amount := MAX(total_amount) FROM orders;
@max_amount
-------------
349.50
(1 row)
ecommerce_db=# SELECT @max_amount AS '最大訂單金額';
最大訂單金額
--------------
349.50
(1 row)

結果與分析: 變量賦值 (SET)、在 WHERE 子句和 SELECT 列表中使用變量均表現正常。查詢結果準確返回了 customer_id=1001 的訂單,并正確計算和顯示了最大訂單金額。語法和行為與 MySQL 完全一致。
測試場景 2:跨語句傳遞與更新
2.1 – 初始化一個計數器變量
SET @order_count := 0;
ecommerce_db=# SET @order_count := 0;
SET

2.2 – 更新訂單狀態并計數 (假設只更新狀態為 ‘NEW’ 的):
ecommerce_db=# UPDATE orders
ecommerce_db-# SET status = 'PROCESSING'
ecommerce_db-# WHERE status = 'NEW'
ecommerce_db-# AND customer_id = @customer_id;
UPDATE 2

2.3 – 獲取受影響行數并累加到計數器:
ecommerce_db=# SET @order_count = @order_count + ROW_COUNT();
SET

2.4 – 顯示處理了多少個新訂單:
ecommerce_db=# SELECT @order_count AS '處理的新訂單數';
處理的新訂單數
----------------
2
(1 row)

結果與分析: 此場景模擬了一個常見操作:使用變量計數。@order_count 成功在 UPDATE 語句后的 SET 語句中被更新,其值基于 ROW_COUNT() 函數(金倉也兼容此函數)累加。最終查詢正確顯示了處理的新訂單數量。這證明了用戶變量在同一個會話內的不同 SQL 語句間有效保持和傳遞數據的能力。
測試場景 3:在存儲過程中使用用戶變量 (PLMYSQL 體現)
雖然用戶變量本身是會話級的,但在兼容 MySQL 的存儲過程(PLMYSQL)中也能無縫使用。
3.1 – 步驟1:創建必要的表:
ecommerce_db=# CREATE TABLE IF NOT EXISTS order_status_summary (
ecommerce_db(# summary_id SERIAL PRIMARY KEY,
ecommerce_db(# summary_date DATE NOT NULL,
ecommerce_db(# status VARCHAR(20) NOT NULL,
ecommerce_db(# order_count INT NOT NULL
ecommerce_db(# );
CREATE TABLE

3.2 – 步驟2:創建存儲過程(修正版):
ecommerce_db=# CREATE OR REPLACE PROCEDURE generate_order_summary()
ecommerce_db-# LANGUAGE plmysql
ecommerce_db-# AS $$
ecommerce_db$# BEGIN
ecommerce_db$# DELETE FROM order_status_summary WHERE summary_date = CURRENT_DATE;
ecommerce_db$# INSERT INTO order_status_summary (summary_date, status, order_count)
ecommerce_db$# SELECT CURRENT_DATE, status, COUNT(*)
ecommerce_db$# FROM orders
ecommerce_db$# GROUP BY status;
ecommerce_db$# END;
ecommerce_db$# $$;
CREATE PROCEDURE

4. 存儲過程語法結構:
4.1 – 無參數的存儲過程示例:
ecommerce_db=# CREATE OR REPLACE PROCEDURE generate_order_summary()
ecommerce_db-# LANGUAGE plmysql
ecommerce_db-# AS $$
ecommerce_db$# BEGIN
ecommerce_db$# DELETE FROM order_status_summary WHERE summary_date = CURRENT_DATE;
ecommerce_db$# INSERT INTO order_status_summary (summary_date, status, order_count)
ecommerce_db$# SELECT CURRENT_DATE, status, COUNT(*) FROM orders GROUP BY status;
ecommerce_db$# END;
ecommerce_db$# $$;
CREATE PROCEDURE

金倉數據庫對MySQL事件調度器的兼容性非常好,但語法細節需要精確匹配。這種"事件調用存儲過程"的模式在實際業務中非常實用,特別適合報表生成、數據清理等定時任務場景。
4.2 – 檢查事件調度器狀態(金倉兼容PostgreSQL風格查詢):
ecommerce_db=# SELECT name, setting
ecommerce_db-# FROM sys_config
ecommerce_db-# WHERE name = 'event_scheduler';
name | setting
------+---------
(0 rows)

4.3 – 或手動觸發事件關聯的存儲過程(驗證邏輯):
ecommerce_db=# CALL generate_order_summary();
CALL

4.4 – 查看執行結果:
ecommerce_db=# SELECT * FROM order_status_summary;
summary_id | summary_date | status | order_count
------------+--------------+------------+-------------
1 | 2025-08-22 | PROCESSING | 3
2 | 2025-08-22 | COMPLETED | 1
(2 rows)

5、 創建該存儲過程
(包含狀態更新、審計日志記錄及用戶變量@old_status的使用):
5.1 – 步驟1:創建必要的表
– 訂單表(假設結構,若已存在可跳過)
ecommerce_db=# CREATE TABLE IF NOT EXISTS orders (
ecommerce_db(# order_id INT PRIMARY KEY,
ecommerce_db(# status VARCHAR(20) NOT NULL,
ecommerce_db(# created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
ecommerce_db(# );
NOTICE: relation "orders" already exists, skipping
CREATE TABLE

5.2 – 審計日志表(記錄狀態變更):
ecommerce_db=# CREATE TABLE IF NOT EXISTS audit_log (
ecommerce_db(# log_id SERIAL PRIMARY KEY,
ecommerce_db(# action VARCHAR(20) NOT NULL,
ecommerce_db(# target_table VARCHAR(50) NOT NULL,
ecommerce_db(# target_id INT NOT NULL,
ecommerce_db(# old_value VARCHAR(20), -- 舊狀態
ecommerce_db(# new_value VARCHAR(20), -- 新狀態
ecommerce_db(# action_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
ecommerce_db(# performed_by VARCHAR(50) DEFAULT CURRENT_USER
ecommerce_db(# );
NOTICE: relation "audit_log" already exists, skipping
CREATE TABLE

5.3 – 步驟2:創建存儲過程update_order_status
ecommerce_db=# CREATE OR REPLACE PROCEDURE update_order_status(
ecommerce_db(# p_order_id INT,
ecommerce_db(# p_new_status VARCHAR(20)
ecommerce_db(# )
ecommerce_db-# LANGUAGE plmysql
ecommerce_db-# AS $$
ecommerce_db$# BEGIN
ecommerce_db$# -- 1. 查詢舊狀態并存儲到用戶變量@old_status
ecommerce_db$# SELECT status INTO @old_status FROM orders WHERE order_id = p_order_id;
ecommerce_db$#
ecommerce_db$# -- 2. 更新訂單狀態
ecommerce_db$# UPDATE orders
ecommerce_db$# SET status = p_new_status
ecommerce_db$# WHERE order_id = p_order_id;
ecommerce_db$#
ecommerce_db$# -- 3. 記錄審計日志(包含舊狀態和新狀態)
ecommerce_db$# INSERT INTO audit_log (
ecommerce_db$# action,
ecommerce_db$# target_table,
ecommerce_db$# target_id,
ecommerce_db$# old_value,
ecommerce_db$# new_value
ecommerce_db$# ) VALUES (
ecommerce_db$# 'Status_Change',
ecommerce_db$# 'orders',
ecommerce_db$# p_order_id,
ecommerce_db$# @old_status,
ecommerce_db$# p_new_status
ecommerce_db$# );
ecommerce_db$# END;
ecommerce_db$# $$;
CREATE PROCEDURE

5.4 – 步驟3:初始化測試數據
插入測試訂單(狀態為’NEW’):
ecommerce_db=# INSERT INTO orders (order_id, status)
VALUES (1, 'NEW') ON CONFLICT DO NOTHING;
WARNING: null value in column "customer_id" violates not-null constraint
WARNING: null value in column "total_amount" violates not-null constraint
INSERT 0 0

關鍵說明
- 存儲過程不存在的原因:之前未創建
update_order_status,需按上述步驟定義,明確參數類型(p_order_id INT、p_new_status VARCHAR(20))。 - 用戶變量
@old_status的使用:在PLMYSQL中,通過SELECT ... INTO @old_status將舊狀態存入會話級變量,后續可直接查詢。 - 審計日志設計:擴展了
audit_log表,增加old_value和new_value字段,更清晰記錄狀態變更軌跡。
執行后,審計日志會顯示訂單1的狀態從NEW變為SHIPPING,@old_status也會返回NEW,符合預期場景。
如果報錯,audit_log表中不存在old_value字段,添加缺失字段
5.5 – 步驟1:修改audit_log表結構,添加缺失字段
-- 為audit_log表添加old_value和new_value字段
ecommerce_db=# ALTER TABLE audit_log
ecommerce_db-# ADD COLUMN IF NOT EXISTS old_value VARCHAR(20),
ecommerce_db-# ADD COLUMN IF NOT EXISTS new_value VARCHAR(20);
ALTER TABLE

5.6 – 步驟2:重新調用存儲過程更新訂單狀態
-- 再次調用存儲過程(此時字段已存在,可正常插入日志)
ecommerce_db=# CALL update_order_status(1, 'SHIPPING');
CALL

5.7 – 步驟3:驗證結果
查看審計日志(應包含舊狀態和新狀態):
ecommerce_db=# SELECT log_id, target_id, old_value, new_value, action_time
ecommerce_db-# FROM audit_log
ecommerce_db-# WHERE action = 'Status_Change';
log_id | target_id | old_value | new_value | action_time
--------+-----------+------------+-----------+---------------------
2 | 1 | PROCESSING | SHIPPING | 2025-08-22 09:31:40
(1 row)
5.8 – 確認訂單狀態已更新:
ecommerce_db=# SELECT order_id, status FROM orders WHERE order_id = 1;
order_id | status
----------+----------
1 | SHIPPING
(1 row)

5.9 – 查看用戶變量@old_status(記錄舊狀態):
ecommerce_db=# SELECT @old_status;
@old_status
-------------
PROCESSING
(1 row)

關鍵原因分析
- 最初創建的
audit_log表可能缺少old_value和new_value字段(與當前存儲過程的插入邏輯不匹配),導致插入日志時觸發“字段不存在”的錯誤。 - 通過
ALTER TABLE添加字段后,存儲過程中的INSERT語句即可正常執行,審計日志能完整記錄狀態變更軌跡。
執行上述步驟后,訂單狀態會從PROCESSING更新為SHIPPING,審計日志會清晰記錄這一變更,@old_status也會正確返回更新前的狀態。
5.10 – 檢查審計日志和變量:
ecommerce_db=# SELECT * FROM audit_log WHERE action = 'Status_Change';
log_id | action | target_table | target_id | action_time | performed_by | old_value | new_value
--------+---------------+--------------+-----------+---------------------+--------------+------------+-----------
2 | Status_Change | orders | 1 | 2025-08-22 09:31:40 | system | PROCESSING | SHIPPING
(1 row)

結果與分析: 存儲過程 update_order_status 成功創建并執行。關鍵點在于:
- 存儲過程使用
LANGUAGE plmysql聲明,表明使用兼容 MySQL 的存儲過程語言。 - 在存儲過程內部,通過
SELECT ... INTO @old_status將查詢結果賦值給用戶變量@old_status。 - 在后續的
INSERT INTO audit_log語句后,我們仍然可以在同一個會話中查詢到@old_status的值,它保存了訂單更新前的狀態。這完美展示了用戶變量在 PLMYSQL 存儲過程內部和外部(同一會話)的可用性,極大地增強了腳本編寫的靈活性。金倉對 PLMYSQL 中用戶變量的支持非常到位。
(二) 事件調度器 (Event Scheduler) 兼容性測試
測試場景 2:創建定時事件 - 定期生成訂單狀態摘要 (使用 PLMYSQL 存儲過程)
更復雜的任務通常會封裝在存儲過程中。
2.1 這里演示事件調用 PLMYSQL 存儲過程。
ecommerce_db=# CREATE OR REPLACE PROCEDURE generate_order_summary()
ecommerce_db-# LANGUAGE plmysql
ecommerce_db-# AS $$
ecommerce_db$# BEGIN
ecommerce_db$# -- 創建一個臨時表或永久表存儲摘要 (這里假設有個 summary_table)
ecommerce_db$# -- 簡化邏輯:將不同狀態的訂單計數插入摘要表
ecommerce_db$# INSERT INTO order_status_summary (summary_date, status, order_count)
ecommerce_db$# SELECT CURRENT_DATE, status, COUNT(*)
ecommerce_db$# FROM orders
ecommerce_db$# GROUP BY status;
ecommerce_db$# END;
ecommerce_db$# $$;
CREATE PROCEDURE

2.2 步驟 2:創建存儲過程(兼容 PL/pgSQL):
ecommerce_db=# CREATE OR REPLACE PROCEDURE generate_order_summary()
ecommerce_db-# LANGUAGE plpgsql -- 使用 PostgreSQL 原生過程語言
ecommerce_db-# AS $$
ecommerce_db$# BEGIN
ecommerce_db$# -- 清空舊數據(假設需要保留歷史)
ecommerce_db$# DELETE FROM order_status_summary WHERE summary_date = CURRENT_DATE;
ecommerce_db$#
ecommerce_db$# -- 插入新摘要
ecommerce_db$# INSERT INTO order_status_summary (summary_date, status, order_count)
ecommerce_db$# SELECT CURRENT_DATE, status, COUNT(*)
ecommerce_db$# FROM orders
ecommerce_db$# GROUP BY status;
ecommerce_db$# END;
ecommerce_db$# $$;
CREATE PROCEDURE

2.2 驗證操作,手動測試存儲過程:
ecommerce_db=# SELECT * FROM order_status_summary;
summary_id | summary_date | status | order_count
------------+--------------+------------+-------------
3 | 2025-08-22 | PROCESSING | 2
4 | 2025-08-22 | SHIPPING | 1
5 | 2025-08-22 | COMPLETED | 1
(3 rows)

3. 性能優化建議
3.1 啟用 SQL 執行統計
ecommerce_db=# ALTER SYSTEM SET shared_preload_libraries = 'sys_stat_statements';
ALTER SYSTEM
ecommerce_db=# SELECT pg_reload_conf();
pg_reload_conf
----------------
t
(1 row)

3.2 使用 KingbaseES 自帶的性能分析工具
查看當前活躍會話:
ecommerce_db=# SELECT * FROM sys_stat_activity;
datid | datname | pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | xact_start | query_start | state_change | wait_event_type | wait_event | state | backend_xid | backend_xmin | query | backend_type
-------+--------------+------+----------+---------+---------------------+-------------+-----------------+-------------+----------------------------+----------------------------+----------------------------+----------------------------+-----------------+---------------------+--------+-------------+--------------+----------------------------------+------------------------------
| | 2211 | | | auto vacuum | | | | 2025-08-20 15:44:20.791964 | | | | Activity | AutoVacuumMain | | | | | autovacuum launcher
12819 | kingbase | 2215 | 10 | system | ksh writer | | | | 2025-08-20 15:44:20.793866 | | | 2025-08-22 10:19:00.677327 | Activity | KshMain | idle | | | | ksh writer
| | 2217 | 10 | system | sys_ksh collector | | | | 2025-08-20 15:44:20.794533 | | | 2025-08-22 10:19:01.001699 | Activity | KshMain | idle | | | | ksh collector
| | 2218 | 10 | system | logical replication | | | | 2025-08-20 15:44:20.795272 | | | | Activity | LogicalLauncherMain | | | | | logical replication launcher
16465 | ecommerce_db | 8763 | 10 | system | ksql | | | -1 | 2025-08-22 09:11:51.448657 | 2025-08-22 10:19:01.433124 | 2025-08-22 10:19:01.433124 | 2025-08-22 10:19:01.433126 | | | active | | 944 | SELECT * FROM sys_stat_activity; | client backend
| | 2209 | | | background flush | | | | 2025-08-20 15:44:20.791115 | | | | Activity | BgWriterMain | | | | | background writer
| | 2208 | | | check pointer | | | | 2025-08-20 15:44:20.790813 | | | | Activity | CheckpointerMain | | | | | checkpointer
| | 2210 | | | wal flush | | | | 2025-08-20 15:44:20.791647 | | | | Activity | WalWriterMain | | | | | walwriter
(8 rows)

3.3 查看鎖等待情況:
KingbaseES 通過 pg_locks 和 pg_stat_activity 系統視圖提供鎖信息:
查看當前所有鎖及持有者:
ecommerce_db=# SELECT
ecommerce_db-# pg_stat_activity.pid AS 進程ID,
ecommerce_db-# pg_stat_activity.query AS 執行語句,
ecommerce_db-# pg_locks.mode AS 鎖模式,
ecommerce_db-# pg_locks.granted AS 是否已獲得鎖
ecommerce_db-# FROM
ecommerce_db-# pg_stat_activity
ecommerce_db-# JOIN pg_locks ON pg_locks.pid = pg_stat_activity.pid
ecommerce_db-# WHERE
ecommerce_db-# pg_stat_activity.state = 'active';
進程ID | 執行語句 | 鎖模式 | 是否已獲得鎖
--------+------------------------------------------------------+-----------------+--------------
8763 | SELECT +| AccessShareLock | t
| pg_stat_activity.pid AS 進程ID, +| |
| pg_stat_activity.query AS 執行語句, +| |
| pg_locks.mode AS 鎖模式, +| |
| pg_locks.granted AS 是否已獲得鎖 +| |
| FROM +| |
| pg_stat_activity +| |
| JOIN pg_locks ON pg_locks.pid = pg_stat_activity.pid+| |
| WHERE +| |
| pg_stat_activity.state = 'active'; | |
8763 | SELECT +| AccessShareLock | t
| pg_stat_activity.pid AS 進程ID, +| |
| pg_stat_activity.query AS 執行語句, +| |
| pg_locks.mode AS 鎖模式, +| |
| pg_locks.granted AS 是否已獲得鎖 +| |
| FROM +| |
| pg_stat_activity +| |
| JOIN pg_locks ON pg_locks.pid = pg_stat_activity.pid+| |
| WHERE +| |
| pg_stat_activity.state = 'active'; | |
8763 | SELECT +| ExclusiveLock | t
| pg_stat_activity.pid AS 進程ID, +| |
| pg_stat_activity.query AS 執行語句, +| |
| pg_locks.mode AS 鎖模式, +| |
| pg_locks.granted AS 是否已獲得鎖 +| |
| FROM +| |
| pg_stat_activity +| |
| JOIN pg_locks ON pg_locks.pid = pg_stat_activity.pid+| |
| WHERE +| |
| pg_stat_activity.state = 'active'; | |
8763 | SELECT +| AccessShareLock | t
| pg_stat_activity.pid AS 進程ID, +| |
| pg_stat_activity.query AS 執行語句, +| |
| pg_locks.mode AS 鎖模式, +| |
| pg_locks.granted AS 是否已獲得鎖 +| |
| FROM +| |
| pg_stat_activity +| |
| JOIN pg_locks ON pg_locks.pid = pg_stat_activity.pid+| |
| WHERE +| |
| pg_stat_activity.state = 'active'; | |
8763 | SELECT +| AccessShareLock | t
| pg_stat_activity.pid AS 進程ID, +| |
| pg_stat_activity.query AS 執行語句, +| |
| pg_locks.mode AS 鎖模式, +| |
| pg_locks.granted AS 是否已獲得鎖 +| |
| FROM +| |
| pg_stat_activity +| |
| JOIN pg_locks ON pg_locks.pid = pg_stat_activity.pid+| |
| WHERE +|
五、 總結與體驗官洞見
經過本次從創建庫表到核心特性深度測試的完整旅程,金倉數據庫 KingbaseES V9 在 MySQL 兼容性,特別是 PLMYSQL 兼容方面的表現給我留下了極其深刻的印象:
- 基礎兼容扎實可靠: 庫、表、索引的創建,數據的增刪改查(CRUD),常用數據類型(
SERIAL/AUTO_INCREMENT,TIMESTAMP,VARCHAR,DECIMAL)和函數(CURRENT_TIMESTAMP,ROW_COUNT(),CURRENT_USER)等基礎 SQL 和 DDL 語法兼容性優異,遷移基礎業務邏輯順暢無阻。 - 用戶變量 (
@varname) 完美兼容: 賦值、在各類SQL語句中的使用、以及跨語句和在PLMYSQL存儲過程中的傳遞和持久化,其行為與MySQL完全一致,是實現復雜業務邏輯的利器。 - 事件調度器 (Event Scheduler) 高度可用: 從事件的定義、調度配置(
EVERY,STARTS)、到直接執行SQL或調用PLMYSQL存儲過程,再到事件的管理和狀態查看,整個流程成熟可靠,為自動化定時任務提供了堅實支撐。 - “平替”實力彰顯,遠超預期: 本次測試的用戶變量和事件調度器,是MySQL應用中非常常見且關鍵的高級特性。金倉對這些特性的成熟、深度兼容,極大地消除了技術遷移的壁壘。它證明了“數據庫平替用金倉”并非一句口號,而是在享受國產化、安全可控優勢的同時,能夠最大程度地保護用戶的現有技術投資和開發習慣,真正做到了平滑、安心替代。
成為金倉產品體驗官的收獲遠超預期: 這次深度體驗不僅是一次技術驗證,更是一次對國產數據庫強大實力的見證。金倉團隊對產品細節的打磨、對兼容性的高度重視以及對開發者體驗的關注,都令人印象深刻。這種開放、透明的體驗官計劃,讓我們能深入核心,與開發者共同成長,助力國產數據庫生態走向繁榮。
#數據庫平替用金倉 #金倉產品體驗官
本文為金倉數據庫產品體驗官原創體驗報告,實測環境基于KingbaseES V9,體驗內容聚焦MySQL兼容特性。文中涉及的具體語法、功能及系統視圖名稱請以您使用的金倉數據庫官方文檔為準。
——以上僅為個人思考與建議,不代表行業普適觀點。文中案例與思路僅供參考,若與實際情況巧合,純屬無意。期待與各位從業者共同探討更多可能!

掃碼關注我們【順華星辰運維棧】了解更多信息




