大事务应拆分为分批小步操作以避免锁表和延迟，优先按主键或时间范围分片，使用索引字段、游标或临时表控制进度，避开高峰、加监控重试，并保障每批事务内闭环与最终一致性。
大事务容易导致锁表、阻塞其他操作、拖慢数据库响应，甚至引发超时或主从延迟。拆分的核心思路是：把“一次性干完一大片”的操作，改成“分批小步快跑”，同时保证业务逻辑正确性和数据一致性。
按主键或时间范围分批次处理
这是最常用也最安全的拆分方式。避免全表扫描和无条件 UPDATE/DELETE，优先选择有索引的字段（如 id、create_time）做分片依据。
- 例如删除半年前日志：不要写 DELETE FROM logs WHERE create_time ，而是每次删 5000 条：
DELETE FROM logs WHERE create_time ，再用上一批的 max(id) 作为下一批起点 - 更新用户状态时，可按 user_id 取模分批：UPDATE users SET status = 2 WHERE id % 100 = 0 AND status = 1;，再轮换余数 1、2……直到全覆盖
用游标或临时表控制进度
当分片逻辑较复杂（比如要关联多表筛选），直接用 LIMIT + ORDER BY 容易漏数据或重复。这时可用游标式遍历或中间表暂存 ID 列表。
- 先建临时表存待处理主键：CREATE TEMPORARY TABLE tmp_ids AS SELECT id FROM orders WHERE status = 0 AND pay_time
- 再分批读取并处理：SELECT id FROM tmp_ids ORDER BY id LIMIT 1000 OFFSET 0;，处理完后 DELETE 对应记录，继续下一批
- 好处是逻辑解耦、可中断重试、不依赖原始表实时状态
避开高峰、加监控与重试机制
拆分不是只改 SQL 就完事，还要配合运维节奏和异常兜底。
- 在低峰期执行（如凌晨 2–4 点），避免影响线上交易
- 每批执行后检查影响行数、耗时、锁等待时间；超过阈值（如单批 > 2 秒 或 影响 > 1w 行）自动暂停或告警
- 封装脚本时加入失败重试（最多 3 次）、跳过已处理 ID、记录断点位置（如最后处理的 id 值），方便续跑
注意事务边界与一致性保障
拆分后每批是独立事务，要防止“部分成功、业务语义错乱”。
- 不要在拆分中跨批次依赖中间状态——比如 A 批更新了金额，B 批才扣库存，应确保单批次内完成闭环操作
- 涉及资金、订单等强一致场景，可在批处理前加应用层分布式锁，或用 select ... for update 锁定当前批次记录
- 必要时配合 binlog 或消息队列异步补发事件，保证最终一致性
不复杂但容易忽略。关键是选对切分维度、控好单批大小、留好退路。实际执行前，务必在测试库压测验证性能与锁表现。
