大事务易致锁等待、undo膨胀与回滚雪崩，须按业务语义拆分：允许中间态可分步提交，禁止中间态则需原子包裹或最终一致性方案。
事务太大，锁就卡死别人
事务执行期间，InnoDB 会为修改的每一行加行锁（或间隙锁），直到 COMMIT 或 ROLLBACK 才释放。事务越长，锁持有时间就越久，其他事务想改同一行就得排队等——轻则延迟升高，重则触发 Lock wait timeout exceeded 报错。
常见诱因包括：
- 在事务里调用外部 HTTP 接口、发 MQ、写日志文件
- 一次性
UPDATE百万行数据，没分批 - 事务内嵌套复杂计算或循环，耗时几十秒以上
undo log 堆积拖垮磁盘和查询性能
RR 隔离级别下，每个事务开启时都会生成一个一致性视图（read view），依赖 undo log 回溯旧版本。事务不提交，undo log 就不能被 purge 线程清理。长期未提交的事务会导致：
-
innodb_undo_tablespaces对应的文件持续膨胀 - 磁盘空间告急，甚至触发
ERROR 1105 (HY000): The total number of locks exceeds the lock table size - 其他长查询因版本链过长而变慢（尤其
SELECT涉及大量历史版本扫描）
大事务回滚成本极高，失败就是雪崩
事务越大，回滚时需要逆向重放的 undo log 就越多。一个 10 分钟才执行完的大事务，若中途失败，回滚可能再耗 15 分钟——期间连接被占、资源不释放、监控报警满天飞。
更危险的是：回滚过程中若遭遇数据库重启，innodb_force_recovery 可能都救不回来，只能靠备份恢复。
所以不是“能不能回滚”，而是“值不值得冒这个险”。生产环境里，DELETE FROM huge_table WHERE ... 这类语句从不裸跑，必须拆成 WHERE id BETWEEN ? AND ? + 分页提交。
拆分事务时最容易忽略的一致性陷阱
把一个逻辑上不可分割的业务动作硬拆成多个事务，可能让中间状态暴露给其他并发请求。比如“扣库存+生成订单”拆开，就可能出现超卖。
关键判断点只有一条：业务上是否允许别人看到这个中间态？
- 允许：比如“记录操作日志”和“更新主表”可拆，日志晚几秒写不影响主流程
- 不允许：比如“减余额+记流水+发通知”，三者必须原子，哪怕慢也要包在一个事务里
- 折中方案：用最终一致性（如本地事务表 + 消息队列），但别指望 MySQL 单实例事务帮你跨服务兜底
真正难的从来不是怎么拆，而是拆哪儿——得看业务语义，不是看 SQL 行数。
