最近項目中的數(shù)據(jù)庫查詢經(jīng)常掛起，應用程序啟動后也報操作超時。測試人員就說數(shù)據(jù)庫又掛了（貌似他們眼中的連接失敗，查詢無果都是掛了），通過 show processlist 一看，滿屏都是 Waiting for table metadata lock 狀態(tài)的連接。第一反應就是kill掉這些連接，奈何連接實在太多，實在kill不過來，于是重啟服務，貌似重啟果真能解決90%的問題，但如果不找到問題原因，問題也肯定會再次出現(xiàn)。
在網(wǎng)上查詢得知MySQL在進行一些alter table等DDL操作時，如果該表上有未提交的事務則會出現(xiàn) Waiting for table metadata lock ，而一旦出現(xiàn)metadata lock，該表上的后續(xù)操作都會被阻塞（詳見 http://www.bubuko.com/infodetail-1151112.html）。所以這個問題需從兩方面解決：
1. 查看未提交事務
從 information_schema.innodb_trx 表中查看當前未提交的事務
select trx_state, trx_started, trx_mysql_thread_id, trx_query from information_schema.innodb_trx\G
（\G作為結(jié)束符時，MySQL Client會把結(jié)果以列模式展示，對于列比較長的表，展示更直觀）
字段意義：
trx_state: 事務狀態(tài)，一般為RUNNING
trx_started: 事務執(zhí)行的起始時間，若時間較長，則要分析該事務是否合理
trx_mysql_thread_id: MySQL的線程ID，用于kill
trx_query: 事務中的sql
一般只要kill掉這些線程，DDL操作就不會Waiting for table metadata lock。
2. 調(diào)整鎖超時閾值
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 。默認值為一年！?。∫芽尴?！將其調(diào)整為30分鐘
set session lock_wait_timeout = 1800; set global lock_wait_timeout = 1800;
好讓出現(xiàn)該問題時快速故障（failfast）
