应查询information_schema.INNODB_TRX中trx_started早于当前时间60秒且trx_state为RUNNING或LOCK WAIT的事务，结合PROCESSLIST识别Command为Sleep但关联活跃事务的“假空闲”连接，定位嵌套事务未正确回滚的代码根因。
查 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 < NOW() - INTERVAL 60 SECOND ORDER BY trx_started LIMIT 10;
如果返回结果里 trx_state 是 RUNNING 或 LOCK WAIT，且 trx_query 是空或明显不该持续这么久的语句（比如只是个 SELECT），基本就是嵌套事务卡在中间没收尾。
-
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% 出现在以下三种写法中：
- 用了
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 连接没用，得先定位到哪段代码在反复开新事务却不收尾。
