分析解决数据库锁Waiting for table metadata lock

参考：
https://www.cnblogs.com/digdeep/p/4892953.html
https://blog.csdn.net/u013235478/article/details/68062939/

1. 查看未提交事务

从 information_schema.innodb_trx 表中查看当前未提交的事务

select trx_state, trx_started, trx_mysql_thread_id, trx_query from information_schema.innodb_trx\G

trx_state: 事务状态，一般为RUNNING
trx_started: 事务执行的起始时间，若时间较长，则要分析该事务是否合理
trx_mysql_thread_id: MySQL的线程ID，用于kill
trx_query: 事务中的sql

2. 调整锁超时阈值

lock_wait_timeout 表示获取metadata lock的超时（单位为秒），允许的值范围为1到31536000（1年）。 默认值为31536000。详见 https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_lock_wait_timeout 。默认值为一年！！！已哭瞎！将其调整为30分钟

set session lock_wait_timeout = 1800;
set global lock_wait_timeout = 1800;

3、查看当前执行的进程

show processlist

1.2 查看表是否太大

show table status like 'tbl_xx' \G

看出表非常小，不存在由于数据量大导致更新慢的问题；

1.3 查看引擎状态

show engine innodb status \G

数据量太大，一屏幕都显示不完，不看了。

既然几个比较直接的方法都查不到原因，那只能更深入的查下了，我打算从数据字典中查下（information_schema，performance_schema）：

1.4，查找当前等待事务：

mysql> select * from  performance_schema .events_waits_current;

Empty set (0.03 sec)

显示空。

查找information_schema中的事件表（EVENTS）、锁等待表（INNODB_LOCK_WAITS），innodb当前出现的锁****（INNODB_LOCKS）均没看到异常（这里就不贴图了）。

1.5 查找事务

既然造成该锁的原因是事务没有提交导致的，那我们应该去查找当前是否有事务在运行（runing注：由于事务一直是runing状态，这也就是为什么我之前查找各种锁都找不到的原因）

mysql> select * from information_schema.innodb_trx;

不过有重大发现：一个trx_mysql_thread_id: 275255348 是从trx_started: 2015-12-03 14:58:45 一直处于runing状态的。

既然我们找到了id了 那我们再回顾使用show processlist查找该ID就行了：

发现了吗，该ID一直是sleep状态。很难发现该进程打开了这个表（可以通过show open tables 查看当前打开的表）。

解决办法：询问了开发这个点的脚本，操作。确认后通过后台mysql 直接kill掉这个进程，业务的alter操作瞬间完成。