MySQL大事务易引发锁表、主从延迟、OOM等问题，优化需拆分事务（按ID/时间分批，每批1000~5000行）、控制范围（移出非必要操作、慎用锁、调优参数）、加强监控（INNODB_TRX、慢查询）并采用替代方案（LOAD DATA、分区清理、归档异步处理）。
MySQL大事务容易导致锁表、主从延迟、内存占用过高甚至OOM，优化核心是“拆分、控制、监控”。
拆分大事务为小事务
避免单个事务处理数万行数据。按主键ID或时间范围分批提交，每批1000~5000行较稳妥。
- 用WHERE条件+LIMIT分页更新，例如：UPDATE t1 SET status=1 WHERE id BETWEEN 10001 AND 20000;
- 在应用层加循环和显式COMMIT，避免在事务中嵌套大量逻辑
- 删除或归档历史数据时，优先用pt-archiver等工具，它自动分批、带休眠、不锁全表
减少事务内操作范围
只在真正需要一致性保障的环节开启事务，非必要查询、日志记录、HTTP调用等移出事务外。
- SELECT语句尽量不用FOR UPDATE或LOCK IN SHARE MODE，除非确需加锁
- 避免在事务中调用慢接口（如外部API）、写文件、发邮件等耗时操作
- 批量插入优先用INSERT ... VALUES (...), (...), (...)而非多条单行INSERT
调整事务相关参数与监控
配合业务节奏合理设置超时与资源限制，及时发现隐患。
- 调低innodb_lock_wait_timeout（默认50秒），避免长等待拖垮连接池
- 监控information_schema.INNODB_TRX，重点关注trx_state、trx_started、trx_rows_modified
- 开启long_query_time=1并捕获未提交事务的慢查询，配合pt-query-digest分析
用替代方案绕过大事务瓶颈
对纯数据迁移、清洗类场景，可考虑更轻量的方式。
- 用LOAD DATA INFILE代替大批量INSERT，速度快且日志更紧凑
- 分区表结合DROP PARTITION或TRUNCATE PARTITION快速清理，不走undo log
- 归档到其他存储（如OSS、HDFS）后异步处理，再通过binlog回放或应用层补偿
不复杂但容易忽略。关键是把“一个大动作”变成“多个可控的小动作”，同时让数据库和应用各司其职。
