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回放或应用层补偿不复杂但容易忽略。关键是把“一个大动作”变成“多个可控的小动作”，同时让数据库和应用各司其职。
