某天某时，发现数据库某表根本无法查询了。
平常呢，在还没有想着深究原因时，就直觉觉得这数据库不稳定。图省事时直接reboot，它有时也确实能解决问题。
而这一次呢，若干小时前才重启了一次，现在又这样，必须要查出原因了。因为即使重启速度再快，有failover的instance，也不可避免会有短暂的影响。何况咱们也不能老停留在只会 reboot的水平吧。
查询进程：
show full processlist;
结果看到很多Waiting for table metadata lock 的信息。还有的是waiting for scheme metadata lock
就是有好多查询语句，因为遇到了lock，它只能等待在那里。
这相当于你看到了很多车堵在那里，但你还是不知道堵车的原因。
还需要继续查。接着上命令：
show engine innodb status;
然后就看到了类似下面的信息：
---TRANSACTION 2139782115, not started MySQL thread id 135, OS thread handle 0x2b63dcb08700, query id 1049918 11.22.33.44 user1 delayed send ok done ---TRANSACTION 2139045227, ACTIVE 11939 sec MySQL thread id 15119, OS thread handle 0x2b63dca86700, query id 972608 22.33.44.55 user2 cleaned up Trx read view will not see trx with id >= 2139046238, sees < 2139046237
最后一条是ACTIVE的，并且占用了11939秒时间，也就是3个多小时的时间，天啦。就是它搞的鬼啦。既然有thread id了。
那就想办法把它Kill掉吧。 因为是用的RDS.直接用kill 15119 命令会提示没权限。
使用下面的命令扫除障碍：
call mysql.rds_kill(15119);
再用show full processlist;查看的话，可以看到之前堵住的查询语句已经不见了。因为LOCK已经解除了，道路已经畅通了呗。 至此，问题得以解决。一股鱼刺卡喉解除了般的舒服。
后续可以进一步了解用户使用的查询语句，看是否是查询语句使用不当，还晨其它原因。
转载请注明：Linc Hu » MySQL数据库某个表卡住原因查找及解决办法