在DB2数据库中，事务（Transaction）是保证数据一致性的核心机制。一个事务内的所有SQL操作，要么通过COMMIT全部生效，要么通过ROLLBACK全部撤销，不存在只执行一半的中间状态。理解并正确使用这两个语句，直接关系到数据的准确性、并发性能以及日志空间的健康程度。本文从事务边界、提交回滚行为、保存点机制和常见问题几个方面，系统梳理DB2事务控制的使用要点。
一、先搞清楚事务的边界在哪里
DB2中一个事务从第一条可执行SQL语句开始，到COMMIT或ROLLBACK执行结束，这中间的所有操作构成一个事务单元。需要注意的是，事务的边界并不仅限于显式写出的SQL，还包括隐式触发的一些行为。
默认情况下，命令行处理器CLP和一些图形工具开启了自动提交（Auto Commit），也就是每执行一条SQL就自动COMMIT一次。这种模式适合临时查询和小量修改，但绝对不能用于业务逻辑要求多条语句原子生效的场景。例如转账操作：扣款和入账必须同生共死，如果第一条语句执行后自动提交，第二条失败时就无法回滚，钱就凭空消失了。
-- 关闭CLP的自动提交，用 +c 参数 db2 +c "UPDATE account SET balance = balance - 500 WHERE id = 1001" db2 +c "UPDATE account SET balance = balance + 500 WHERE id = 1002" db2 COMMIT
上面的示例中，+c参数表示该语句执行后不自动提交，最后手动执行COMMIT才真正落库。在应用程序中，JDBC连接可以通过setAutoCommit(false)来关闭自动提交，效果类似。判断事务边界的原则很简单：凡是业务上要求要么全成功、要么全失败的逻辑单元，就应该放在同一个事务里。
二、COMMIT与ROLLBACK的具体行为分析
COMMIT的作用是把当前事务中所有修改永久写入数据库。执行COMMIT时，DB2会做几件事：将日志缓冲区刷新到事务日志、释放该事务持有的所有锁、让其他等待这些锁的并发事务得以继续、关闭当前打开的游标（默认情况下）。理解这些附带行为很重要，尤其是锁的释放，它直接影响并发性能。
ROLLBACK则相反，它利用事务日志把数据恢复到事务开始前的状态，同样会释放持有的锁。典型的使用场景是在异常处理中兜底：捕获到SQL异常后立即回滚，避免脏数据残留。下面是一个存储过程中的标准写法：
CREATE OR REPLACE PROCEDURE transfer_audit()
BEGIN
DECLARE SQLSTATE CHAR(5);
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION
BEGIN
ROLLBACK; -- 出错时回滚整个事务
RESIGNAL; -- 把异常抛给调用方
END;
UPDATE audit_log SET status = 'P' WHERE date = CURRENT DATE;
INSERT INTO audit_summary (date, cnt)
SELECT date, COUNT(*) FROM audit_log
WHERE status = 'P' GROUP BY date;
COMMIT; -- 全部成功后提交
END
需要特别注意COMMIT与游标的关系。默认情况下执行COMMIT会关闭所有打开的游标（用WITH HOLD选项声明的除外）。如果你在一个循环中一边读游标一边更新数据，并且定期COMMIT释放锁，那么必须用DECLARE cur CURSOR WITH HOLD FOR ...来声明游标，否则提交后游标失效，下一次FETCH就会报SQLSTATE 24501错误。
三、用SAVEPOINT实现事务内的部分回滚
有时候并不需要撤销整个事务，只需要回退到某个中间点。DB2提供了SAVEPOINT机制，允许在事务内部设置保存点，ROLLBACK TO SAVEPOINT只撤销保存点之后的操作，之前的修改依然有效。这在批量处理中逐条尝试、失败跳过的场景下非常实用。
INSERT INTO orders VALUES (1001, 'A'); SAVEPOINT sp1; INSERT INTO order_items VALUES (1001, 1, 10); ROLLBACK TO SAVEPOINT sp1; -- 只撤销order_items的插入 INSERT INTO order_items VALUES (1001, 1, 5); -- 重新插入 COMMIT; -- 最终orders和order_items都生效
使用保存点有几个要点：第一，ROLLBACK TO SAVEPOINT之后保存点本身默认仍然保留，可以再次回退到同一位置；如果想释放它，用RELEASE SAVEPOINT sp1。第二，保存点只在当前事务内有效，COMMIT或ROLLBACK之后全部失效。第三，保存点的回滚同样遵循原子性，不会把保存点之前已经执行的修改一并撤销。
四、长事务的危害与提交频率的权衡
事务不是越长越好。一个长事务会长时间持有锁，导致其他事务阻塞等待，严重时引发锁等待超时（SQLSTATE 40001）或死锁（SQLSTATE 40003）；同时未提交的修改必须记录在事务日志中，超长事务会让日志空间快速膨胀，甚至触发日志满错误SQL0964C，直接导致事务回滚失败。
批量处理大量数据时，推荐的做法是分批提交：每处理一批记录（例如一万条，视行大小和日志容量而定）就COMMIT一次，同时配合WITH HOLD游标保证循环继续。示例骨架如下：
DECLARE cur CURSOR WITH HOLD FOR
SELECT id FROM big_table WHERE flag = 0;
OPEN cur;
FETCH FROM cur INTO :vid;
WHILE (SQLCODE = 0) DO
UPDATE big_table SET flag = 1 WHERE id = :vid;
SET :cnt = :cnt + 1;
IF MOD(:cnt, 10000) = 0 THEN
COMMIT; -- 每一万条提交一次，释放锁并落盘日志
END IF;
FETCH FROM cur INTO :vid;
END WHILE;
COMMIT;
反过来，提交也不能过于频繁。每条语句一个事务的开销主要体现在日志写入和锁管理上，高并发场景下会明显拖慢吞吐。合理的策略是：在保证业务原子性的前提下，尽量缩短事务持续时间；事务内不要夹杂耗时操作（比如等待外部接口返回、人工审批），把不必要的逻辑移到事务外执行。
五、常见坑与排查建议
实际使用中有几个高频问题值得留意。其一，自动提交开着却以为是手动事务，结果异常时想ROLLBACK却发现数据早已落库，应用上线前务必确认连接的提交模式。其二，在COMMIT后继续使用旧游标，导致SQLSTATE 24501这类无效游标错误，提交后应重新打开游标再继续处理。其三，把DDL和DML混在一个事务里，某些DDL操作会隐式结束当前事务，行为因版本和对象类型而异，稳妥的做法是DDL单独提交。
排查锁和事务相关问题，可以用db2 list applications show detail查看当前连接状态，用db2 get snapshot for locks on 数据库名分析锁等待链，结合监控表函数定位长事务的来源。日志使用率可以通过数据库快照中的日志空间指标观察，接近上限时就要警惕是否有长事务没有提交。
总结一下：DB2事务控制的精髓在于正确划定事务边界、理解COMMIT与ROLLBACK的完整行为（包括锁释放和游标失效）、善用SAVEPOINT做精细控制、并通过合理的提交频率在数据安全与并发性能之间取得平衡。把这些要点落实到日常开发中，数据一致性和系统稳定性都会有一个扎实的保障。