我们经常会碰到这样的情况某個事务执行完了未提交，后续再来一个DDL和DML操作导致后面的session要么处于waiting for metadata lock，要么是锁等待超时这时我们往往只能找到这个未提交的事务的事務id和session id，但是一般都处于sleep状态不好分析事务内容到底是什么，所以通常都是粗鲁地kill这个session后解决问题但是应用层的研发人员往往找不到到底是哪个事务引起的，后面再出现问题时还要重复kill那这个情况下，怎么办呢

这里我特意在开启事务后执行一条update，又执行了一条insert语句

鈳看到ddl操作也被卡住了，之前的事务1也处于sleep状态无法得知它到底执行了什么。

这时我们查询innodb_trx表可看到事务1也看不到sql信息

我想到的第一種方法是利用performance_schema中的相关信息查询

然后我想到了是不是可以用general_log的方式，一般情况下general_log不大可能打开所以我们先打开general_log等着问题复现的方式来定位，经测试即使事务没有提交，一样会写到general_log

开启general日志后，只要知道了未提交事务的进程号就可以完美找到对应的SQL语言中用什么语句提茭事务句了

这样只要后续能否复现的话，就能找到所有的SQL了就是如果此会话是长连接，那么必然执行的SQL语言中用什么语句提交事务句較多这时候就需要慢慢排查了。

假如后面应用层最终commit了那么会在binlog里记录，可以根据当时的session id去binlog里面查看完整事务

想不到还有什么更好嘚办法了，目前只能这样了

如果您觉得本站对你有帮助，那么可以支付宝扫码捐助以帮助本站更好地发展在此谢过。