mysql5.7.10 出现waiting for table metadata lock

遇到个innodb表被锁住的问题，表的任何操作都不可以正常进行，

>show processlist; 

发现多个该表的查询进程的状态为waiting for table metadata lock，巧的发现表被锁的同时正在对表进行DDL操作，所以当下的猜测是DDL操作的同时有人改表数据啦各种猜测，猜来猜去还是得逐个排查，其中有个说法是如果存在对该表的任何操作的事务没有commit会出现上述情况，顺着这条线查，

首先查找没有提交的事务（一直处于RUNNING状态的）

>SELECT * FROM information_schema.INNODB_TRX(INNODB_LOCKS|INNODB_LOCK_WAITS)  

还真发现两条正在RUNNING的事物，根据结果返回的trx_mysql_thread_id ， 根据这个ID去show processlist结果中去查找对应的ID字段和trx_mysql_thread_id是相同的进程，获取该连接的host及用户信息，从而锁定导致表锁定的使用者是谁。到这一步问题仍未解决，查看mysql日志，发现很多连接中断的信息及 Got an error reading communication packets提示：

将错误提示信息Got an error reading communication packets， 在mysql的参考手册中去查找相关结果（搜索关键字自己视情况而定）

在结果页面中找到同时包含 Aborted connection和communication error关键字的内容，连接为https://dev.mysql.com/doc/refman/5.7/en/communication-errors.html

注意到手册中提到的其中一个原因：

再根据之前找出的造成死锁的用户，将导致死锁的一直在的事物的线程手动kill掉，让刚才的登录用户继续跑其应用，这时候发现又出现一直在RUNNNING状态的事物，让其检查发现咩有调用mysql_close相关的，加上mysql_close调用后，不会出现一直没有提交的事物。到此以为，以为问题全部定位。但是注意到了另一个会造成的原因，

也就是说当连接没有断开时，sleep的时间大于wait_timeout和interactive_timeou设置的值时也会导致日志中问题的出现（默认值28800s=8小时）。于是重新开启没有调用close的应用，发现即使存在咩有提交的事物也可以对表进行其他正常查询写入操作，又对比了下之前事物的开始时间，从开始到现在存在时间并未超过8小时， 而且事物开始RUNNING前一段时间是没有出现metatable lock的情况。此时联想到了表死锁是发生在DDL操作的时候的，再一搜：

总算是彻底找到原因，其实如果之前就具备这样的只是储备，查到

>SELECT * FROM information_schema.INNODB_TRX结果时就可以完全定位问题了，不过周折一圈后也倒是收获不少，遗憾的事白天的例子咩有截图，有时间完整重现下案例。意识到自己知识的储备太欠缺了，后续赶上。