COMMIT 将事务修改永久写入数据库并释放资源，ROLLBACK 则撤销所有未提交更改并释放锁；二者均作用于 START TRANSACTION 之后、COMMIT 之前的操作，DDL 会隐式提交导致无法回滚。

COMMIT 和 ROLLBACK 的本质区别是：一个把未落盘的修改“钉死”进数据库，另一个则把它们彻底抹掉，回到事务开始前的样子。

什么时候该用 COMMIT？

当你确认这一组操作全部成功、业务逻辑无误、数据状态符合预期时，才执行 COMMIT。

• 它不可逆——一旦执行，就再也无法通过 ROLLBACK 撤销
• 其他会话立刻能查到这些更改（取决于隔离级别，但已对一致性视图可见）
• 底层会触发 redo log 刷盘，确保崩溃后也能恢复
• 事务结束后自动关闭，后续语句进入新事务或自动提交模式

START TRANSACTION;
UPDATE bank_account SET balance = balance - 100 WHERE name = '张三';
UPDATE bank_account SET balance = balance + 100 WHERE name = '李四';
COMMIT;  -- 此刻转账完成，不可反悔

什么时候必须用 ROLLBACK？

只要事务中任意一步出错（SQL 报错、应用层判断失败、用户中途取消），就该立即 ROLLBACK，否则脏数据可能残留或锁住资源。

• 只对 START TRANSACTION 之后、尚未 COMMIT 的操作生效
• 回滚后，所有 DML（INSERT/UPDATE/DELETE）变更被丢弃，行锁释放
• 注意：ROLLBACK 不能回滚到某条语句之前，只能回到事务起点（除非用了 SAVEPOINT）
• DDL（如 DROP TABLE）在执行时会隐式提交当前事务，无法被回滚

START TRANSACTION;
DELETE FROM orders WHERE status = 'pending' AND created_at < '2025-01-01';
-- 发现删多了，赶紧撤
ROLLBACK;  -- 这条 DELETE 完全不生效

为什么默认 autocommit=1 会让你“回滚失效”？

这是最常踩的坑：MySQL 默认每条 DML 都自动提交，ROLLBACK 找不到可回滚的事务上下文。

• 执行 SELECT @@autocommit; 返回 1，说明你正处在自动提交模式
• 此时单独写 ROLLBACK; 不报错，但什么也不会发生——因为根本没有开启事务
• 正确做法是先关自动提交：SET autocommit = 0;，再 START TRANSACTION;
• 注意：SET autocommit = 0 只对当前会话有效；永久修改需改 my.cnf

事务控制不是“开关”，而是一套状态流转

事务不是静态配置，而有明确生命周期：从 START TRANSACTION 开始，到 COMMIT 或 ROLLBACK 结束。中间任何异常（断连、kill 连接、客户端崩溃）都会触发隐式回滚。

• COMMIT 和 ROLLBACK 都会结束当前事务，下一条 DML 自动开启新事务（在 autocommit=0 下）或直接提交（在 autocommit=1 下）
• 不要依赖“长时间不提交就能一直 hold 住数据”——长事务会占锁、拖慢 MVCC、甚至引发 undo log 膨胀
• 真正难的不是语法，而是业务上如何定义“原子操作边界”：转账要包两步，订单创建+库存扣减也得包一起

别把 COMMIT 当保存按钮，也别把 ROLLBACK 当后悔药——它们是同一枚硬币的两面，共同服务于一个目标：让数据库在出错时，还能相信自己没撒谎。