长事务会显著增加MySQL的锁竞争、内存消耗和主从延迟，严重时导致系统雪崩；其持有锁时间长引发阻塞、undo日志膨胀、purge阻塞、MVCC查询变慢、主从延迟加剧、连接池耗尽等问题。
长事务会显著增加 MySQL 的锁竞争、内存消耗和主从延迟，严重时导致系统雪崩。
锁资源长期占用，阻塞并发操作
事务开启后，其涉及的行锁或表锁不会在语句执行完就释放，而是持续到事务提交或回滚。如果一个事务运行几十秒甚至几分钟，它持有的锁会让其他需要访问相同数据的事务长时间等待，表现为 大量线程处于 Waiting for table metadata lock 或 Locked 状态。例如，一个未加 LIMIT 的 UPDATE 语句在大表上扫描全表并更新，又没及时提交，后续所有对该表的 DDL（如 ALTER TABLE）和部分 DML 都会被卡住。
- 行级锁升级为表级锁的风险上升（尤其在 RR 隔离级别下，GAP 锁范围扩大）
- 死锁概率随事务时长和并发度同步提高
- SHOW PROCESSLIST 中可见大量 State 为 Sending data 或 Updating 的长时间运行连接
Undo 日志持续膨胀，引发性能与空间危机
长事务不提交，MySQL 就不能清理该事务开始前已失效的 undo log。这些日志不仅占用磁盘空间，还会拖慢 purge 线程工作，造成 undo 表空间暴涨、历史版本链过长、MVCC 查询变慢。极端情况下，undo 表空间写满直接导致写入阻塞。
- InnoDB 的 purge 操作被阻塞，导致 history list length 持续增长（可通过 SHOW ENGINE INNODB STATUS 查看）
- SELECT 查询因要遍历更长的版本链而变慢，尤其在高并发读场景下明显
- 若使用独立 undo 表空间且配置了 autoextend，可能意外占满磁盘
主从延迟加剧，一致性难以保障
主库上的长事务在从库回放时仍需保持原子性，无法拆分。一个耗时 3 分钟的事务，在从库上也必须连续执行完才能更新 seconds_behind_master。这会导致 从库延迟突增、监控报警频繁、读写分离场景下读到过期数据。
- 即使主库已提交，从库的 SQL Thread 仍处于 “Reading event from the relay log” 或 “Executing event” 状态
- 基于 GTID 的复制中，长事务会拉长 Executed_Gtid_Set 的推进节奏，影响故障切换判断
- 延迟过大时，应用层“先写后读”的逻辑容易读不到刚写入的数据
连接与内存资源被无效占用
每个事务对应一个活跃连接，长事务意味着连接长期不可复用。在连接数有限（如 max_connections=500）的实例中，几十个长事务就能把连接池耗尽，新请求直接报错 Too many connections。同时，事务私有内存（如 sort_buffer、join_buffer）和共享内存（如 innodb_log_buffer）也会被长期持有。
- information_schema.PROCESSLIST 中 Time 值持续增长，且 Command 多为 Sleep 或 Query
- Performance Schema 中 memory/performance_schema/* 模块可能显示异常内存分配
- 配合应用连接池（如 HikariCP）时，连接泄漏 + 长事务易引发连接池打满、请求排队超时
