MySQL 8.0.34同连接下存储过程调用时INNODB_TRX旧事务显示问题

针对你在MySQL 8.0.34中遇到的同一连接下，调用新存储过程E时仍能在information_schema.INNODB_TRX中看到之前存储过程A的CALL事务处于运行状态的问题，主要有以下几种可能原因：

1. 事务未被显式终止 #

MySQL的事务基于连接上下文而非单个存储过程。如果存储过程A（或其内部嵌套的B/C/D）中开启了事务（比如执行START TRANSACTION/BEGIN，或修改autocommit=0），但在A执行完成后未通过COMMIT或ROLLBACK显式终止事务，该连接的事务会持续处于活跃状态。此时调用存储过程E，E会在同一个未终止的事务上下文内执行，INNODB_TRX中显示的"运行中"事务其实是同一连接的未结束事务，而非A的CALL操作仍在运行。

2. INNODB_TRX的统计延迟 #

information_schema.INNODB_TRX中的数据并非实时同步，它是InnoDB事务系统的快照视图，更新依赖于InnoDB内部统计逻辑。在高负载场景下，或事务状态刚发生变化时，该视图信息可能滞后于实际事务状态，导致你看到之前事务的残留记录。

3. 存储过程嵌套的事务上下文继承 #

MySQL不支持真正的嵌套事务，存储过程嵌套调用会继承当前连接的事务上下文。如果A执行过程中因某些操作（如autocommit=0下的DML语句）隐式开启事务，且未在A结束时提交/回滚，连接的事务状态会一直保持。即使A已执行完成，连接的活跃事务依然存在，INNODB_TRX会继续显示该事务信息，直到事务被显式终止或连接关闭。

验证建议 #

• 检查存储过程A及其内部嵌套的存储过程代码，确认是否存在未提交/回滚的事务逻辑，比如是否遗漏COMMIT/ROLLBACK语句，或错误修改autocommit参数后未恢复。
• 在调用E之前，手动执行COMMIT或ROLLBACK，再查询INNODB_TRX，观察事务是否消失，以此验证是否是事务未终止导致的问题。
• 多次间隔查询INNODB_TRX，如果"运行中"的事务记录在一段时间后消失，说明是视图统计延迟导致的。

内容的提问来源于stack exchange，提问作者Floobinator