MySQL不建议在长连接中运行大事务，核心原因是未及时提交的大事务会持续占用内存（如undo log、一致性读视图）并长期持有行锁，导致OOM、锁阻塞、连接池耗尽及死锁风险上升。
MySQL 不建议在长连接中运行大事务，核心原因不是“长连接”本身有问题，而是长连接 + 未及时提交的大事务，会同时放大内存占用和锁持有风险——这两者在生产环境常互为诱因，最终触发 OOM 或服务不可用。
长连接里没 COMMIT 的事务，会让内存持续涨到失控
每个 MySQL 连接（哪怕处于 Sleep 状态）都独占一份线程栈（thread_stack，默认 256KB–1MB）、排序缓冲区（sort_buffer_size）、临时表内存（tmp_table_size）等资源。而一旦该连接上启用了事务且未 COMMIT 或 ROLLBACK，InnoDB 还会：
- 持续保留 undo log 版本，阻止 purge 线程清理旧数据，导致
innodb_undo_log_truncate失效、undo 表空间膨胀 - 维持一致性读视图（consistent read view），使 MVCC 快照无法回收，历史版本堆积在 buffer pool 和磁盘上
- 若事务中执行了大结果集查询（如全表扫描 +
ORDER BY），还会额外占用临时内存/磁盘临时表空间
典型表现：SHOW PROCESSLIST 里一堆 Sleep 连接，但 performance_schema.memory_summary_by_thread_by_event_name 显示某几个线程的 memory/innodb/undo_log 或 memory/sql/Query_cache 持续飙升。
大事务在长连接中会把行锁“焊死”十几秒甚至几分钟
InnoDB 的行锁不是按语句释放，而是按事务生命周期释放。一个在长连接中执行了 20 秒才 COMMIT 的事务，意味着它从第一条 UPDATE 开始就持有对应行/间隙锁，直到最后提交。这直接引发：
- 其他事务访问相同主键或范围时被阻塞，
State变成Locked或Waiting for table metadata lock - 高并发下连接池迅速耗尽（比如 HikariCP 的
maximumPoolSize=20，20 个长事务就把池占满） - 死锁概率指数上升：事务持有锁越多、时间越长，与其他事务形成循环等待的可能性越大
注意：autocommit=0 的连接（常见于某些 ORM 的手动事务模式）极易踩这个坑——一次查询后忘了 COMMIT，后续所有操作都在同一个未结束事务里累积锁和内存开销。
连接池配置不当会让问题雪上加霜
长连接本身无害，但连接池若缺乏主动治理能力，会让“带病连接”长期滞留：
-
idle_timeout（HikariCP）或minEvictableIdleTimeMillis（Druid）设得过大（如默认 10 分钟），导致空闲但含未提交事务的连接不被驱逐 - 未开启泄漏检测（如 HikariCP 的
leak_detection_threshold=60000），无法发现应用层忘记close()或异常分支遗漏rollback() -
max_lifetime过长（如设为 30 分钟），让一个已执行过多次大事务的连接继续复用，undo log 和内存碎片越积越多
实操建议：把 idle_timeout 收紧到 60–180 秒，配合应用层确保每个事务块都有明确的 try/finally 或 @Transactional(timeout = 5) 控制。
真正危险的从来不是“单次大事务”，而是“长连接里反复开启、却不收尾的大事务”——它让内存和锁的消耗不再是一次性的，而是持续累积、缓慢泄漏。排查时别只盯 top 里的 RSS，要进 performance_schema 看线程级内存分布，再结合 information_schema.INNODB_TRX 找出 TIME_TO_SEC(NOW() - trx_started) > 5 的活事务。
