怎样排查MySQL由于事务嵌套异常导致的连接暴涨-mysql教程-PHP中文网

应查询information_schema.innodb_trx中trx_started早于当前时间60秒且trx_state为running或lock wait的事务，结合processlist识别command为sleep但关联活跃事务的“假空闲”连接，定位嵌套事务未正确回滚的代码根因。

怎样排查mysql由于事务嵌套异常导致的连接暴涨

查 `information_schema.INNODB_TRX` 里长时间未提交的事务

事务嵌套异常最直接的表现是外层事务没提交，内层又开了新事务（比如 Spring 的 @Transactional(propagation = REQUIRES_NEW) 在异常分支里反复触发），导致 trx_started 时间远超业务预期。重点不是看“有没有事务”，而是看“有没有该结束却不结束的事务”。

执行这条 SQL：

SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id, trx_query 
FROM information_schema.INNODB_TRX 
WHERE trx_started <p>如果返回结果里 <code>trx_state</code> 是 <code>RUNNING</code> 或 <code>LOCK WAIT</code>，且 <code>trx_query</code> 是空或明显不该持续这么久的语句（比如只是个 <code>SELECT</code>），基本就是嵌套事务卡在中间没收尾。</p>

trx_mysql_thread_id 要和 SHOW PROCESSLIST 里的 Id 对上，确认是哪个连接在持有着它
注意 trx_started 时间戳是否比应用日志里报错时间早很多——说明事务早在异常发生前就挂住了
如果 trx_query 是 NULL，大概率是应用端已断开但事务没 rollback，MySQL 还在等它

对照 `SHOW PROCESSLIST` 看 Sleep 连接是否绑定着活跃事务

事务嵌套异常常伴随大量 Sleep 连接，但这些连接不是真空闲——它们背后绑着一个没提交的事务，锁还挂着，MDL 也占着。关键要识别这种“假 Sleep”。

运行：

SELECT p.Id, p.User, p.Host, p.db, p.Command, p.Time, p.State, p.Info,
       t.trx_id, t.trx_state, t.trx_started
FROM information_schema.PROCESSLIST p
LEFT JOIN information_schema.INNODB_TRX t ON p.Id = t.trx_mysql_thread_id
WHERE p.Command = 'Sleep' AND p.Time > 60
ORDER BY p.Time DESC;

重点关注那些 Command = 'Sleep' 但 t.trx_id 非空、t.trx_state = 'RUNNING' 的行。这类连接就是“表面睡着，实际在 hold 锁”的典型。

别只看 Time 是否超 wait_timeout；即使 Time=120，只要它关联着事务，就不能认为是可回收的空闲连接
如果 Host 列显示的是同一台应用服务器的多个连接，且都挂着事务，大概率是那个服务实例里某段嵌套逻辑出问题了
State 是 Sleep，不代表线程安全；InnoDB 层的事务状态才是真实水位

检查应用层事务传播与异常处理路径

数据库侧只能看到“有事务没结束”，但根因一定在代码里。嵌套异常导致连接暴涨，90% 出现在以下三种写法中：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

用了 REQUIRES_NEW 但 catch 了异常却没手动 rollback，导致新事务一直 open
外层事务抛异常回滚，但内层 REQUIRES_NEW 事务没被感知，继续跑着并占用连接
try-catch 里调了带事务的方法，catch 后既没 re-throw 也没显式 commit/rollback，框架无法自动清理

排查时直接搜代码库里的关键词：@Transactional.*REQUIRES_NEW、TransactionTemplate.execute、PlatformTransactionManager。重点看所有 catch 块是否包含事务清理逻辑。

一个简单验证方式：在测试环境模拟相同调用链路，开启 spring.jpa.show-sql=true 和 logging.level.org.springframework.transaction=DEBUG，观察日志里事务 begin/commit/rollback 是否成对出现。

警惕 `innodb_rollback_on_timeout` 关闭带来的滞留

默认情况下，MySQL 在锁等待超时（innodb_lock_wait_timeout）后会自动 rollback 当前语句，但不会 rollback 整个事务。如果应用没捕获 LockWaitTimeoutException 并主动 rollback，这个事务就会一直挂着，后续所有操作都失败，连接却不会释放。

检查当前配置：

SHOW VARIABLES LIKE 'innodb_rollback_on_timeout';

如果返回 OFF（MySQL 5.7 默认值），那任何锁等待超时都不会终止事务，极易造成“一个超时，全链卡死”。

线上建议设为 ON，避免单点超时拖垮整个事务上下文
但要注意：设为 ON 后，超时会导致整个事务回滚，需确保业务能容忍这种级联回滚
配合应用层监控 DeadlockLoserDataAccessException 和 LockWaitTimeoutException 日志，比单纯看连接数更早发现问题

真正难缠的不是事务嵌套本身，而是嵌套之后异常没被正确传播或处理，让事务变成“幽灵状态”——看不见 SQL，查不到阻塞，但连接和锁都实实在在占着资源。这时候光 kill 连接没用，得先定位到哪段代码在反复开新事务却不收尾。