MySQL长事务会显著影响数据库性能与稳定性，主要体现在锁资源占用、主从延迟、undo日志膨胀、内存压力及复制中断风险；其持续持锁阻塞并发、阻碍undo清理、拉长复制延迟、消耗内存资源，并易因应用异常导致孤立事务。
MySQL长事务会显著影响数据库性能与稳定性，主要体现在锁资源占用、主从延迟、undo日志膨胀、内存压力以及复制中断风险等方面。
锁等待加剧，阻塞并发操作
长事务会持续持有行锁或表锁，导致其他事务在访问相同数据时被挂起等待。尤其是更新密集型业务中，一个运行数分钟的事务可能让几十个后续请求排队，出现明显的响应延迟甚至超时。
- UPDATE/DELETE语句若未及时提交，对应记录的排他锁不会释放
- SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 同样会长期持锁
- InnoDB的锁信息可通过 SELECT * FROM information_schema.INNODB_TRX 查看事务运行时长和锁状态
Undo日志持续增长，磁盘空间告急
长事务要求InnoDB保留旧版本数据（MVCC），以便其他事务能读取快照。这意味着undo log不能被及时清理，可能快速占满ibdata1或独立undo表空间。
- undo log大小与事务修改的数据量及持续时间正相关
- 即使设置了innodb_undo_log_truncate=ON，长事务也会阻止undo表空间截断
- 可通过 SHOW ENGINE INNODB STATUS 中的 HISTORY LIST 长度判断undo积压程度
主从延迟飙升，复制可靠性下降
主库上的长事务在从库回放时是单线程串行执行（尤其在MySQL 5.7及之前），一个耗时10分钟的事务会让整个复制延迟至少10分钟，且期间无法应用后续binlog事件。
- GTID模式下虽支持多线程复制，但同一事务仍需完整串行回放
- 从库SQL线程卡在某个大事务上，Seconds_Behind_Master 持续增大
- 极端情况下可能导致relay log堆积、磁盘写满或复制中断
内存与连接资源被无效占用
每个活跃事务都会占用一定的内存（如事务系统结构体、锁对象、缓冲区等），长事务数量多时会推高buffer pool外的内存开销，并拖慢事务分配与清理速度。
- information_schema.INNODB_TRX 中的 TRX_STARTED 时间可识别“睡眠中但未提交”的事务
- 客户端异常断开而服务端未自动回滚（如wait_timeout未触发），会留下孤立事务
- 建议设置 interactive_timeout 和 wait_timeout 合理值，配合应用层超时控制
不复杂但容易忽略：多数长事务并非业务必需，而是由应用未正确关闭连接、异常未回滚、或批量逻辑设计不合理导致。定期监控 + 主动kill + 代码层事务粒度收敛，是最有效的防控组合。
