事务回滚仅对同一连接中未提交的dml有效，commit后或autocommit=1下操作不可逆；myisam不支持事务；需先set autocommit=0并确认引擎为innodb，再用savepoint分段控制。
事务回滚只对未提交的 DML 有效
你不能靠 ROLLBACK 撤销已经 COMMIT 的操作，也不能回滚跨连接、跨会话的更改。回滚生效的前提非常具体：必须在同一个连接中，显式开启事务（BEGIN 或 START TRANSACTION），且所有 DML 都未提交。一旦执行了 COMMIT，或者连接断开、autocommit=1 下单条语句自动提交，就彻底不可逆。
常见误判场景：
- 执行完几条
UPDATE后直接关了客户端，以为还能ROLLBACK—— 实际上 autocommit=1 时每条都已提交 - 用
SHOW CREATE TABLE table_name确认是 MyISAM 引擎，却仍尝试事务控制 —— MyISAM 不支持事务，ROLLBACK无任何效果 - 事务中混入
ALTER TABLE—— DDL 会隐式触发COMMIT，前面的 DML 就再也回不去了
测试前必须关闭 autocommit 并确认引擎
默认 autocommit=1 是最大陷阱。测试批量 DML 前，第一件事就是关掉它：
SET autocommit = 0;
然后立刻验证：
SELECT @@autocommit;
返回 0 才算生效。接着检查目标表引擎：
SHOW CREATE TABLE users;
确保输出里包含 ENGINE=InnoDB。如果不是，ALTER TABLE users ENGINE=InnoDB; 转换后再测。别跳过这步 —— InnoDB 是唯一能保证行级锁+事务日志+崩溃恢复的引擎。
用保存点（savepoint）做分段验证和局部回滚
复杂批量操作常含多个逻辑阶段（比如先删旧数据、再插新数据、最后更新统计表）。全塞进一个事务里，出错就得全盘推倒重来。用 SAVEPOINT 可以拆解控制粒度：
BEGIN;<br>DELETE FROM order_history WHERE created_at SAVEPOINT after_delete;<br><br>INSERT INTO order_history SELECT * FROM order_archive WHERE status = 'done';<br>SAVEPOINT after_insert;<br><br>UPDATE summary SET total_orders = (SELECT COUNT(*) FROM order_history);<br>-- 如果这步报错，只回滚到 insert 后：<br>ROLLBACK TO after_insert;
注意：ROLLBACK TO savepoint_name 不会结束事务，后续仍可继续执行其他语句或最终 COMMIT；而裸 ROLLBACK 会回到事务起点并终止事务。
避免长事务导致锁表和主从延迟
批量操作越长，锁持有时间越久，阻塞其他连接的风险越高，主从延迟也可能飙升。实操建议：
- 单次事务处理不超过 5000 行（视服务器配置调整），大任务拆成循环批次，每批
COMMIT后再启新事务 - 不要在事务里做耗时查询（如
SELECT ... FOR UPDATE锁住大量行后停顿几秒） - 测试脚本开头加
SELECT NOW(), CONNECTION_ID();，方便出问题时快速定位是哪个连接卡住了 - 生产环境严禁直接跑未验证的批量脚本 —— 先在同结构但无业务流量的库上完整走一遍
BEGIN → 执行 → SELECT 核对 → ROLLBACK
真正容易被忽略的是 DDL 的隐式提交和 binlog_format 的影响：哪怕你全程手动控制事务，如果 binlog_format 不是 ROW，后续靠 binlog 恢复时也会丢细节。测试环境可以不管，但只要涉及线上试错，这个配置必须提前对齐。
