xmlns="http://www.w3.org/2000/svg"

style="display:

/>

引言

在实际业务当中，不少操作要“多步同步完成或者同步失败”，就像转账时，从A账户扣款并给B账户入账，如果仅仅扣了款却没有入账，就会引发数据错误，所以要用“事务”来保证数据的一致性，本文就“ksql命令行运作事务”展开论述，按照“事务概念——基本操作——隔离级别——问题查找”的顺序层层分解，利用通俗易懂的语言和实际业务案例（比如转账）加以阐述，使得初学者也能够领会事务的关键意义及其操作手段。

/>

/>

文章目录

• 引言
• • 一、前置准备：确认操作环境（衔接前文，确保示例可落地）
  • • 1.1

      确认测试表与数据（用转账场景的表为例）

  • 二、核心概念：事务与

    ACID

    特性（新手必懂）

  • 三、事务控制命令：3

    启动事务：BEGIN

    提交事务：COMMIT（确认操作，永久生效）

  • 3.3

    回滚事务：ROLLBACK（撤销操作，恢复原状）

  • 3.4

    “自动提交”

    特性（新手必知坑）

• 四、事务隔离级别：解决

  “多事务干扰”

  先懂问题：隔离级别要解决什么？

• 4.2

  KingbaseES

  隔离级别操作：查看与修改

• • 3.1

    查看当前隔离级别

  • 3.2

修改隔离级别（当前会话生效）

3.3

REPEATABLE

为例）

五、查看与管理活跃事务：避免

“锁表”

pg_stat_activity）

5.2

终止异常事务（需管理员权限）

六、常见问题排查：事务操作的

1：事务未提交导致锁表，其他事务无法修改

问题

3：事务回滚后数据丢失（误以为提交了）

问题

4：执行

语句后事务自动提交

七、总结：事务使用的核心建议

一、前置准备：确认操作环境（衔接前文，确保示例可落地）

事务操作依赖已有的表和数据，需先完成以下准备，避免示例执行失败：

1.1

用有权限的用户连接数据库

事务操作包含INSERT，UPDATE，DELETE等，执行这些操作时，用户要具有表操作的权限，推荐以管理员用户system或者像前面创建的test这样的被授权用户来建立连接，其中test要有test_schema.sys_user表的UPDATE权限。

#
kingbase
模式（使用前文创建的表）SET
search_path
public;

1.2

确认测试表与数据（用转账场景的表为例）

为了靠近实际业务，我们形成“账户表

account”（用以取代复杂场景），而且加入测试数据（后面会用转账例子来阐述事务）。

#
创建账户表（id：账户ID，balance：余额）CREATETABLEIFNOTEXISTSaccount(idINTPRIMARYKEY,balanceNUMERIC(10,2)NOTNULLCHECK(balance>=0)--
余额不能为负);#
插入测试数据（A账户1000元，B账户2000元）INSERTINTOaccount(id,balance)VALUES(1,1000.00),(2,2000.00);#
验证数据（确认初始余额正确）SELECT*FROMaccount;

执行后若显示以下结果，说明准备完成：

ACID

特性（新手必懂）

在学习操作之前，要先领会“事务”的实质，所谓事务，就是“一组无法分割的SQL操作”，这个组的操作或者全部执行完毕（提交），或者全部不执行（回滚），不存在仅部分执行的情况。

事务应具备ACID特性，这是数据一致性的关键保障，可以用“转账场景”来简单阐述：

“保障

个核心命令玩转事务

KingbaseES经由BEGIN（开始）,COMMIT（提交）,ROLLBACK（回滚）这3个命令来控制事务，其操作较为简单，不过一定要严格按照流程来，下面结合“转账示例”详细阐述一下。

3.1

启动事务：BEGIN

TRANSACTION

在执行一系列“原子操作”之前，首先要启动事务，并告知数据库“后续的操作将形成一个整体”

/>语法（两种写法均可）：

BEGIN;--
或STARTTRANSACTION;

示例（启动转账事务）：

#
启动事务BEGIN;#
执行转账操作（A账户id=1扣200，B账户id=2加200）UPDATEaccountSETbalance=balance-200WHEREid=1;--
A扣款UPDATEaccountSETbalance=balance+200WHEREid=2;--
“未提交”
状态，此时数据仅在当前会话可见（其他会话看不到修改），需执行COMMIT或ROLLBACK结束事务。
3.2
提交事务：COMMIT（确认操作，永久生效）
执行完毕之后，事务就会处于“未提交”的状态，在这种情况下，数据只会出现在当前会话当中（其他会话无法看到这些改动），而且必须要执行COMMIT或者ROLLBACK来结束事务。
/>语法：
COMMIT;
示例（提交转账事务）：
#
提交事务（让扣款和入账永久生效）COMMIT;#
验证结果（查看A、B账户余额）SELECT*FROMaccount;
执行结果（符合预期，总金额仍为
3000）：
/>
3.3
回滚事务：ROLLBACK（撤销操作，恢复原状）
事务中的某一步如果出现错误，比如在转账的时候把B账户ID写错了，造成入账失败，那么就要执行ROLLBACK来撤销所有的操作，使得数据回到事务开始之前的状态，然后事务就结束了。
/>语法：
ROLLBACK;
示例（模拟错误并回滚）：
#
先恢复初始数据（A=1000，B=2000）UPDATEaccountSETbalance=1000WHEREid=1;UPDATEaccountSETbalance=2000WHEREid=2;#
启动新事务，模拟错误（B账户ID写成3，不存在）BEGIN;UPDATEaccountSETbalance=balance-200WHEREid=1;--
A扣款成功（余额800）UPDATEaccountSETbalance=balance+200WHEREid=3;--
B账户不存在，执行失败#
rows
updated”，说明入账失败）#
回滚事务（撤销A的扣款，恢复到初始状态）ROLLBACK;#
验证结果（A余额回到1000，B仍为2000）SELECT*FROMaccount;
执行结果（数据恢复，无损失）：
/>
3.4
特性（新手必知坑）
KingbaseES
默认情况下，“自动提交”（auto_commit
=
on）会被打开，也就是说，每次执行INSERT/UPDATE/DELETE语句时，数据库都会自动隐式提交事务，就像是每条语句都是单独的事务一样。
/>查看自动提交状态：
SHOWauto_commit;
关闭自动提交（适合多步操作需作为事务的场景）：
SETauto_commit=off;
提醒：关闭自动提交后，所有操作需手动COMMIT才生效，若关闭会话未提交，会自动回滚。
四、事务隔离级别：解决
“多事务干扰”
问题
若众多事务一同操作同一组数据，则有可能产生“脏读”“不可重复读”“幻读”之类的问题，KingbaseES凭借“事务隔离级别”来控制事务之间的隔离水平，KingbaseES具备4种标准的隔离级别，应当按照业务需求加以选用。
4.1
先懂问题：隔离级别要解决什么？
用
“两个事务操作同一张表”
种）
不同隔离级别解决的问题不同，性能也不同（隔离级别越高，性能越低），默认级别为READ
COMMITTED：
/>
4.3
隔离级别操作：查看与修改
3.1
查看当前隔离级别
SHOWTRANSACTIONISOLATIONLEVEL;
默认结果：read
committed
修改隔离级别（当前会话生效）
语法：
SETTRANSACTIONISOLATIONLEVEL隔离级别;
示例
1：修改为
READ（解决不可重复读）：
SETTRANSACTIONISOLATIONLEVELREPEATABLEREAD;
/>
示例
SERIALIZABLE（金融场景）：
SETTRANSACTIONISOLATIONLEVELSERIALIZABLE;
提醒：修改隔离级别后，需重新启动事务（BEGIN）才会生效。
3.3
REPEATABLE
的解决：
会话
A：设置隔离级别为REPEATABLE
READ，启动事务，查询
账户余额：
SETTRANSACTIONISOLATIONLEVELREPEATABLEREAD;BEGIN;SELECTbalanceFROMaccountWHEREid=1;--
结果：1000.00
会话
B：修改
账户余额并提交：
BEGIN;UPDATEaccountSETbalance=900WHEREid=1;COMMIT;SELECTbalanceFROMaccountWHEREid=1;--
结果：900.00
会话
账户余额（仍为
1000.00，解决不可重复读）：
SELECTbalanceFROMaccountWHEREid=1;--
结果：1000.00（不受会话B影响）COMMIT;--
提交后，再次查询会显示900.00
五、查看与管理活跃事务：避免
“锁表”
问题
如果事务长时间未提交，比如在执行BEGIN之后忘记了COMMIT或ROLLBACK，那么就会锁定相关的表或者行，使得其他的事务无法执行修改操作，要掌握如何查看这些异常活跃的事务，并知道如何去终止它们。
5.1
查看活跃事务（用系统视图
pg_stat_activity）
SELECTpid,--
事务进程IDusename,--
执行事务的用户datname,--
数据库名query,--
事务状态（active=活跃）FROMpg_stat_activityWHEREstate='active'ANDqueryLIKE'BEGIN%'ORqueryLIKE'UPDATE%';
/>
结果解读：若看到query包含BEGIN/UPDATE且state=active，说明是未提交的活跃事务。
5.2
终止异常事务（需管理员权限）
若某事务长时间活跃（如
pid=1234），执行以下命令终止：
SELECTpg_terminate_backend(1234);--
1234
pid
验证：终止后，原事务会自动回滚，锁定的表
行会释放。
六、常见问题排查：事务操作的
“高频坑”
问题
1：事务未提交导致锁表，其他事务无法修改
报错信息：
ERROR:
could
lock.
原因：进程
1234
的事务未提交，锁定了account表的行。
/>解决方案：
查看活跃事务，找到锁定进程的
pid（如
1234）：
SELECTpid,queryFROMpg_stat_activityWHERErelation='account'::regclass;
终止该进程：
SELECTpg_terminate_backend(1234);
问题
2：隔离级别过低导致脏读
场景：事务
读到事务
/>原因：当前隔离级别为READ
UNCOMMITTED（允许脏读）。
/>解决方案：将隔离级别提升到READ
COMMITTED及以上：
SETTRANSACTIONISOLATIONLEVELREADCOMMITTED;
问题
3：事务回滚后数据丢失（误以为提交了）
场景：执行UPDATE后未COMMIT，断开会话再连接，数据恢复原状。
/>原因：KingbaseES
/>解决方案：事务操作完成后，务必执行COMMIT确认提交，可通过SELECT验证结果。
问题
4：执行
语句后事务自动提交
场景：在事务中执行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
会自动提交，不要和
放在同一事务中。
掌握事务运作之后，你就具有了
KingbaseES
数据一致性保障的关键能力，到此为止，关于从“连接数据库”到“事务控制”的整个
ksgl
的日常运作情况，如果想要进一步深入学习，可以留意后面进阶的部分（比如分区表，备份还原等），如果有期待学习的内容，可以直接在评论区留言或者给我发私信。