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

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

我们洅开一个窗口session3。

可看到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里面查看完整事务。