大事务卡死或超时本质是锁和日志拖慢mysql：长事务持续持锁、狂写redo、撑爆undo，导致mvcc版本链拉长、查询变慢；应拆分为1k～5k行/批，禁用offset分页，改用游标式推进。
大事务卡死或超时，本质是锁和日志在拖慢你
MySQL里一个跑十几分钟的事务，不是“慢”，而是正在持续持有行锁、表锁，同时往ib_logfile里狂写redo日志，还可能把undo log撑爆。InnoDB默认事务隔离级别下，长事务会让MVCC版本链无限拉长，其他查询也跟着变慢。
拆分不是为了“看起来快”，是为了让锁及时释放、日志可控、回滚不爆炸。
- 别用
AUTOCOMMIT=0包住整批数据处理——这是最常见误操作 - 单次提交控制在 1k～5k 行较稳妥；超过 1w 行就得警惕
Lock wait timeout exceeded - 避免在事务里做网络请求、文件读写、复杂计算——这些会把锁持有时长不可控地拉长
用 LIMIT + WHERE 拆 UPDATE/DELETE，别信 OFFSET
想分批更新千万级用户状态？别写UPDATE users SET status=1 ORDER BY id LIMIT 1000 OFFSET 100000——OFFSET越往后越慢，MySQL得扫过前10w行才能定位起点。
正确做法是用上一批最后的id作为下一批起点，变成游标式推进：
UPDATE users SET status = 1 WHERE id > 12345 AND id
- 必须确保
WHERE条件字段有索引（比如id主键或status+id联合索引） - 每次执行后记录最大
id值，下次用它当边界，而不是靠计数器 - 加
AND status = 0这类业务条件，防止重复执行时误改已处理数据
INSERT … SELECT 大量数据时，关掉 autocommit + 手动分段
INSERT INTO t2 SELECT * FROM t1 WHERE ...看着简洁，但整个SELECT结果集会一次性进事务，锁表+刷日志全来一遍。尤其t1有千万行时，基本等于堵死整张表。
换成带循环的客户端逻辑更可控：
- 用
SELECT id FROM t1 WHERE ... ORDER BY id LIMIT 1000先取ID列表 - 拼
INSERT INTO t2 SELECT * FROM t1 WHERE id IN (1,2,...)批量插入 - 每批执行完立刻
COMMIT，别等循环结束再提交 - 如果源表也在写入，加
FOR UPDATE要慎重——可能引发死锁，优先考虑一致性读+时间戳标记
拆分后还得防隐性事务陷阱
你以为手动COMMIT就万事大吉？DML语句在某些配置下仍可能被自动包裹：比如SET SESSION autocommit = 0后没显式BEGIN，第一条UPDATE就开启新事务，后续忘了COMMIT，这个“空挂起”事务会一直占着锁和undo空间。
- 执行前先查
SELECT @@autocommit，确认是1；如果不是，要么设回去，要么明确用BEGIN/START TRANSACTION - 监控
INFORMATION_SCHEMA.INNODB_TRX表，定期查trx_started时间过长的事务 - 应用层加超时控制：比如Python用
connection.timeout = 30，Go用context.WithTimeout，别让一个分支卡住整个流程
真正难的不是拆成多少段，而是每段之间怎么保证状态可追踪、失败可重入、并发不冲突——边界条件比主逻辑更值得花时间想清楚。
