
引言
在实际业务当中,不少操作要"多步同步完成或者同步失败",就像转账时,从A账户扣款并给B账户入账,如果仅仅扣了款却没有入账,就会引发数据错误,所以要用"事务"来保证数据的一致性,本文就"ksql命令行运作事务"展开论述,按照"事务概念------基本操作------隔离级别------问题查找"的顺序层层分解,利用通俗易懂的语言和实际业务案例(比如转账)加以阐述,使得初学者也能够领会事务的关键意义及其操作手段。 
@[toc]
一、前置准备:确认操作环境(衔接前文,确保示例可落地)
事务操作依赖已有的表和数据,需先完成以下准备,避免示例执行失败:
1.1 1. 用有权限的用户连接数据库
事务操作包含INSERT,UPDATE,DELETE等,执行这些操作时,用户要具有表操作的权限,推荐以管理员用户system或者像前面创建的test这样的被授权用户来建立连接,其中test要有test_schema.sys_user表的UPDATE权限。
bash
# 连接 kingbase 数据库,用户为 system
ksql -d kingbase -U system
# 切换到 test_schema 模式(使用前文创建的表)
SET search_path TO test_schema, public;
1.2 2. 确认测试表与数据(用转账场景的表为例)
为了靠近实际业务,我们形成"账户表 account"(用以取代复杂场景),而且加入测试数据(后面会用转账例子来阐述事务)。
sql
# 1. 创建账户表(id:账户ID,balance:余额)
CREATE TABLE IF NOT EXISTS account (
id INT PRIMARY KEY,
balance NUMERIC(10,2) NOT NULL CHECK (balance >= 0) -- 余额不能为负
);
# 2. 插入测试数据(A账户1000元,B账户2000元)
INSERT INTO account (id, balance) VALUES (1, 1000.00), (2, 2000.00);
# 3. 验证数据(确认初始余额正确)
SELECT * FROM account;
执行后若显示以下结果,说明准备完成:

二、核心概念:事务与 ACID 特性(新手必懂)
在学习操作之前,要先领会"事务"的实质,所谓事务,就是"一组无法分割的SQL操作",这个组的操作或者全部执行完毕(提交),或者全部不执行(回滚),不存在仅部分执行的情况。事务应具备ACID特性,这是数据一致性的关键保障,可以用"转账场景"来简单阐述:

后续所有事务操作,都是围绕 "保障 ACID 特性" 展开的。
三、事务控制命令:3 个核心命令玩转事务
KingbaseES经由BEGIN(开始), COMMIT(提交), ROLLBACK(回滚)这3个命令来控制事务,其操作较为简单,不过一定要严格按照流程来,下面结合"转账示例"详细阐述一下。
3.1 1. 启动事务:BEGIN / START TRANSACTION
在执行一系列"原子操作"之前,首先要启动事务,并告知数据库"后续的操作将形成一个整体" 语法(两种写法均可):
sql
BEGIN; -- 推荐,简洁
-- 或
START TRANSACTION;
示例(启动转账事务):
sql
# 1. 启动事务
BEGIN;
# 2. 执行转账操作(A账户id=1扣200,B账户id=2加200)
UPDATE account SET balance = balance - 200 WHERE id = 1; -- A扣款
UPDATE account SET balance = balance + 200 WHERE id = 2; -- B入账

执行后,事务处于 "未提交" 状态,此时数据仅在当前会话可见(其他会话看不到修改),需执行 COMMIT 或 ROLLBACK 结束事务。
3.2 2. 提交事务:COMMIT(确认操作,永久生效)
执行完毕之后,事务就会处于"未提交"的状态,在这种情况下,数据只会出现在当前会话当中(其他会话无法看到这些改动),而且必须要执行 COMMIT 或者 ROLLBACK 来结束事务。 语法:
sql
COMMIT;
示例(提交转账事务):
sql
# 1. 提交事务(让扣款和入账永久生效)
COMMIT;
# 2. 验证结果(查看A、B账户余额)
SELECT * FROM account;
执行结果(符合预期,总金额仍为 3000):

3.3 3. 回滚事务:ROLLBACK(撤销操作,恢复原状)
事务中的某一步如果出现错误,比如在转账的时候把B账户ID写错了,造成入账失败,那么就要执行ROLLBACK来撤销所有的操作,使得数据回到事务开始之前的状态,然后事务就结束了。 语法:
sql
ROLLBACK;
示例(模拟错误并回滚):
sql
# 1. 先恢复初始数据(A=1000,B=2000)
UPDATE account SET balance = 1000 WHERE id = 1;
UPDATE account SET balance = 2000 WHERE id = 2;
# 2. 启动新事务,模拟错误(B账户ID写成3,不存在)
BEGIN;
UPDATE account SET balance = balance - 200 WHERE id = 1; -- A扣款成功(余额800)
UPDATE account SET balance = balance + 200 WHERE id = 3; -- B账户不存在,执行失败
# 3. 查看错误(ksql会提示"0 rows updated",说明入账失败)
# 4. 回滚事务(撤销A的扣款,恢复到初始状态)
ROLLBACK;
# 5. 验证结果(A余额回到1000,B仍为2000)
SELECT * FROM account;
执行结果(数据恢复,无损失):

3.4 4. 事务的 "自动提交" 特性(新手必知坑)
KingbaseES 默认情况下,"自动提交"(auto_commit = on)会被打开,也就是说,每次执行 INSERT/UPDATE/DELETE 语句时,数据库都会自动隐式提交事务,就像是每条语句都是单独的事务一样。 查看自动提交状态:
sql
SHOW auto_commit;
关闭自动提交(适合多步操作需作为事务的场景):
sql
SET auto_commit = off;
提醒 :关闭自动提交后,所有操作需手动 COMMIT 才生效,若关闭会话未提交,会自动回滚。
四、事务隔离级别:解决 "多事务干扰" 问题
若众多事务一同操作同一组数据,则有可能产生"脏读""不可重复读""幻读"之类的问题,KingbaseES凭借"事务隔离级别"来控制事务之间的隔离水平,KingbaseES具备4种标准的隔离级别,应当按照业务需求加以选用。
4.1 1. 先懂问题:隔离级别要解决什么?
用 "两个事务操作同一张表" 的场景,解释常见问题: 
4.2 2. KingbaseES 支持的隔离级别(4 种)
不同隔离级别解决的问题不同,性能也不同(隔离级别越高,性能越低),默认级别为 READ COMMITTED:

4.3 3. 隔离级别操作:查看与修改
3.1 查看当前隔离级别
sql
SHOW TRANSACTION ISOLATION LEVEL;
默认结果 :read committed 
3.2 修改隔离级别(当前会话生效)
语法:
sql
SET TRANSACTION ISOLATION LEVEL 隔离级别;
示例 1:修改为 REPEATABLE READ(解决不可重复读):
sql
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

示例 2:修改为 SERIALIZABLE(金融场景):
sql
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
提醒 :修改隔离级别后,需重新启动事务(BEGIN)才会生效。
3.3 隔离级别效果演示(以 REPEATABLE READ 为例)
用两个 ksql 会话(会话 A、会话 B)演示 "不可重复读" 的解决:
-
会话 A :设置隔离级别为
REPEATABLE READ,启动事务,查询 A 账户余额:sqlSET TRANSACTION ISOLATION LEVEL REPEATABLE READ; BEGIN; SELECT balance FROM account WHERE id = 1; -- 结果:1000.00 -
会话 B:修改 A 账户余额并提交:
sqlBEGIN; UPDATE account SET balance = 900 WHERE id = 1; COMMIT; SELECT balance FROM account WHERE id = 1; -- 结果:900.00 -
会话 A:再次查询 A 账户余额(仍为 1000.00,解决不可重复读):
sqlSELECT balance FROM account WHERE id = 1; -- 结果:1000.00(不受会话B影响) COMMIT; -- 提交后,再次查询会显示900.00
五、查看与管理活跃事务:避免 "锁表" 问题
如果事务长时间未提交,比如在执行 BEGIN 之后忘记了 COMMIT 或 ROLLBACK,那么就会锁定相关的表或者行,使得其他的事务无法执行修改操作,要掌握如何查看这些异常活跃的事务,并知道如何去终止它们。
5.1 1. 查看活跃事务(用系统视图 pg_stat_activity)
sql
SELECT
pid, -- 事务进程ID
usename, -- 执行事务的用户
datname, -- 数据库名
query, -- 事务执行的SQL
state -- 事务状态(active=活跃)
FROM pg_stat_activity
WHERE state = 'active' AND query LIKE 'BEGIN%' OR query LIKE 'UPDATE%';

结果解读 :若看到 query 包含 BEGIN/UPDATE 且 state=active,说明是未提交的活跃事务。
5.2 2. 终止异常事务(需管理员权限)
若某事务长时间活跃(如 pid=1234),执行以下命令终止:
sql
SELECT pg_terminate_backend(1234); -- 1234 为事务的 pid
验证:终止后,原事务会自动回滚,锁定的表 / 行会释放。
六、常见问题排查:事务操作的 "高频坑"
问题 1:事务未提交导致锁表,其他事务无法修改
报错信息:
plaintext
ERROR: could not obtain lock on row in relation "account"
DETAIL: Process 1234 is holding the lock.
原因 :进程 1234 的事务未提交,锁定了 account 表的行。
解决方案:
-
查看活跃事务,找到锁定进程的 pid(如 1234):
sqlSELECT pid, query FROM pg_stat_activity WHERE relation = 'account'::regclass; -
终止该进程:
sqlSELECT pg_terminate_backend(1234);
问题 2:隔离级别过低导致脏读
场景 :事务 A 读到事务 B 未提交的修改,后来事务 B 回滚,事务 A 的数据错误。
原因 :当前隔离级别为 READ UNCOMMITTED(允许脏读)。
解决方案 :将隔离级别提升到 READ COMMITTED 及以上:
sql
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
问题 3:事务回滚后数据丢失(误以为提交了)
场景 :执行 UPDATE 后未 COMMIT,断开会话再连接,数据恢复原状。
原因 :KingbaseES 对未提交的事务,断开会话时会自动回滚。
解决方案 :事务操作完成后,务必执行 COMMIT 确认提交,可通过 SELECT 验证结果。
问题 4:执行 DDL 语句后事务自动提交
场景 :在事务中执行 CREATE TABLE 后,之前的 UPDATE 被自动提交,无法回滚。
原因 :KingbaseES 中 DDL 语句(CREATE/ALTER/DROP)会隐式触发 COMMIT,终止当前事务。
解决方案 :事务中避免混合 DDL 和 DML(INSERT/UPDATE/DELETE)操作,若需执行 DDL,单独作为一个事务。
七、总结:事务使用的核心建议
本文完整覆盖了事务的 "概念→操作→隔离级别→问题排查",核心建议可总结为:
-
记住事务三个命令:"BEGIN"开始,"COMMIT"确认,"ROLLBACK"撤销,防止出现"未提交"或者"误回滚"的情况。
-
隔离级别依需求选定 :普通业务采用默认的
READ COMMITTED,统计用途REPEATABLE READ,而金融类则选用SERIALIZABLE来兼顾性能与一致性。 -
避免长时间事务:启动事务后尽快完成操作并提交,防止锁表影响其他业务;
-
DML/DDL 分开用:DDL 会自动提交,不要和 DML 放在同一事务中。
掌握事务运作之后,你就具有了 KingbaseES 数据一致性保障的关键能力,到此为止,关于从"连接数据库"到"事务控制"的整个 ksgl 命令行操作的讲解就完毕了,可以应对多数 KingbaseES 的日常运作情况,如果想要进一步深入学习,可以留意后面进阶的部分(比如分区表,备份还原等),如果有期待学习的内容,可以直接在评论区留言或者给我发私信。