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 当后悔药——它们是同一枚硬 币的两面，共同服务于一个目标：让数据库在出错时，还能相信自己没撒谎。
