大事务拆分是提升MySQL并发性能与稳定性的关键，需按业务语义分批处理、游标分页、临时表+异步补偿，并注意连接与事务配置。
大事务在 MySQL 中容易引发锁等待、主从延迟、内存占用过高甚至 OOM，拆分事务是提升并发性能和稳定性的关键手段。核心思路是：把一个长时间持有锁、扫描大量数据、写入多行的“巨无霸事务”，拆成多个小而快的事务，中间通过业务逻辑或状态控制保证一致性。
识别并定位大事务
先确认哪些事务真正属于“大事务”。不只是执行时间长，关键是：锁住的行数多、扫描的行数多、生成的 binlog 大、事务内包含大量 INSERT/UPDATE/DELETE。
- 查活跃长事务：SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 60;
- 看事务扫描量：SHOW ENGINE INNODB STATUS\G 中关注 mysql tables in use 和 rows examined
- 结合慢日志（log_slow_admin_statements=ON）过滤带有 COMMIT 的慢查询，常暴露提交阶段卡顿的大事务
按业务语义合理拆分
不能为拆而拆，必须保障业务正确性。常见可拆分场景：
-
批量导入/同步：10 万行数据插入，不要单个事务全包。按 500~5000 行分批，每批独立事务，失败只重试当前批次
-
状态批量更新：如“将所有待处理订单更新为已发货”，可按 order_id 范围或时间分片（WHERE create_time BETWEEN ? AND ?），避免全表扫描+全表加锁
-
复杂计算+落库：先在应用层完成聚合/校验，再用小事务写结果；避免在事务内做 RPC、文件读写、循环调用等耗时操作
用游标或分页替代全量加载
避免在事务中 SELECT ... FOR UPDATE 扫描几十万行。改用基于主键/自增 ID 的游标分页：
- 第一次：SELECT * FROM t WHERE id > 0 ORDER BY id LIMIT 1000 FOR UPDATE
- 记下本次最大 id（比如 12345），下次查询 WHERE id > 12345，继续取下一批
- 配合应用层循环处理，每次事务只锁 1000 行，释放快、冲突少、主从复制压力
小
善用临时表与最终一致性补偿
对无法强一致拆分的场景（如跨库/跨服务更新），可用“两阶段”思路：
- 第一阶段：小事务写入本地 task_log 表（记录要做的动作 + 状态=‘pending’）
- 第二阶段：异步任务（如定时 Job 或消息队列消费者）拉取 pending 任务，逐条执行并更新状态为 ‘done’ 或 ‘failed’
- 关键点：task_log 表主键/唯一键防重，执行前先 SELECT ... FOR UPDATE + 状态校验，避免重复执行
不复杂但容易忽略：拆分后记得检查 autocommit 是否关闭、连接是否复用、是否有隐式事务（如 DDL 后自动 commit）。小事务不是银弹，需配合索引优化、读写分离和监控告警一起落地。
小