今天在同步測試數據時，網突然斷了，等到重連之后，發現表打不開了。
可以看到表的數據長度已有 112192kb，可惜打不開了。
打不開，就準備刪掉重來。
事情往往沒這么簡單，果然刪不掉，truncate 也不行，然后 navicat 卡死，遂登上數據庫，執行 dorp 操作，還是不行。
估計是網絡錯誤，導致了一些奇怪的事情發生。
那么就一起看看，到底發生了什么吧。
神器登場。
show full processlist;
show full processlist 返回的結果是實時變化的，是對 mysql 鏈接執行的現場快照，所以用來處理突發事件非常有用。
這個 sql，一般就是充當救火隊員的角色，解決一些突發性的問題。
它可以查看當前 mysql 的一些運行情況，是否有壓力，都在執行什么 sql，語句耗時幾何，有沒有慢 sql 在執行等等。
當發現一些執行時間很長的 sql 時，就需要多注意一下了，必要時 kill 掉，先解決問題。
命令有三種執行方式：
1、這種是直接在命令行查詢，末尾帶 G 是表示將查詢結果進行按列打印，可以使每個字段打印到單獨的行。
mysql>?show?full?processlist; +--------+------+----------------------+-------+---------+------+----------+-----------------------+ |?Id?????|?User?|?Host?????????????????|?db????|?Command?|?Time?|?State????|?Info??????????????????| +--------+------+----------------------+-------+---------+------+----------+-----------------------+ |?449000?|?root?|?127.123.213.11:59828?|?stark?|?Sleep???|?1270?|??????????|?NULL??????????????????| |?449001?|?root?|?127.123.213.11:59900?|?stark?|?Sleep???|?1241?|??????????|?NULL??????????????????| |?449002?|?root?|?127.123.213.11:59958?|?stark?|?Sleep???|?1216?|??????????|?NULL??????????????????| |?449003?|?root?|?127.123.213.11:60088?|?stark?|?Sleep???|?1159?|??????????|?NULL??????????????????| |?449004?|?root?|?127.123.213.11:60108?|?stark?|?Sleep???|?1151?|??????????|?NULL??????????????????| |?449005?|?root?|?127.123.213.11:60280?|?stark?|?Sleep???|?1076?|??????????|?NULL??????????????????| |?449006?|?root?|?127.123.213.11:60286?|?stark?|?Sleep???|?1074?|??????????|?NULL??????????????????| |?449007?|?root?|?127.123.213.11:60344?|?stark?|?Sleep???|?1052?|??????????|?NULL??????????????????| |?449008?|?root?|?127.123.213.11:60450?|?stark?|?Sleep???|?1005?|??????????|?NULL??????????????????| |?449009?|?root?|?127.123.213.11:60498?|?stark?|?Sleep???|??986?|??????????|?NULL??????????????????| |?449013?|?root?|?localhost????????????|?NULL??|?Query???|????0?|?starting?|?show?full?processlist?| +--------+------+----------------------+-------+---------+------+----------+-----------------------+ 11?rows?in?set?(0.01?sec) mysql>?show?full?processlistG; ***************************?1.?row?*************************** ?????Id:?449000 ???User:?root ???Host:?127.123.213.11:59828 ?????db:?stark Command:?Sleep ???Time:?1283 ??State:? ???Info:?NULL ***************************?2.?row?*************************** ?????Id:?449001 ???User:?root ???Host:?127.123.213.11:59900 ?????db:?stark Command:?Sleep ???Time:?1254 ??State:? ???Info:?NULL
2、通過查詢鏈接線程相關的表來查看快照
select id, db, USER, HOST, command, time, state, info FROM information_schema. PROCESSLIST WHERE command != ‘Sleep’ ORDER BY time DESC;
3、通過 navicat 中的【工具】=> 【服務器監控】進行查看。
這種方式比較方便，還可以排序。
簡單介紹一下，每列的含義：
Id：鏈接 mysql 服務器線程的唯一標識，可以通過 kill 來終止此線程的鏈接。
User：當前線程鏈接數據庫的用戶
Host：顯示這個語句是從哪個 ip 的哪個端口上發出的。可用來追蹤出問題語句的用戶
db: 線程鏈接的數據庫，如果沒有則為 null
Command: 顯示當前連接的執行的命令，一般就是休眠或空閑（sleep），查詢（query），連接（connect）
Time: 線程處在當前狀態的時間，單位是秒
State：顯示使用當前連接的 sql 語句的狀態，很重要的列，后續會有所有的狀態的描述，請注意，state 只是語句執行中的某一個狀態，一個 sql 語句，已查詢為例，可能需要經過 copying to tmp table，Sorting result，Sending data 等狀態才可以完成
Info: 線程執行的 sql 語句，如果沒有語句執行則為 null。這個語句可以使客戶端發來的執行語句也可以是內部執行的語句
發現問題之后怎樣解決它呢？
1、可以單獨 kill 掉上面有問題的行
kill 449000
2、也可以批量結束時間超過 3 分鐘的線程
— 查詢執行時間超過3分鐘的線程，然后拼接成 kill 語句
select concat(‘kill ‘, id, ‘;’)
from information_schema.processlist
where command != ‘Sleep’
and time > 3*60
order by time desc;
當然問題到這，一般都能解決了，但是本次在 show processlist 過程中，只是看到了前面的 truncate 和 drop 操作，把這兩個線程 kill 了，也沒啥用。。。。
當然上面這些不是廢話昂，這就是類似方法論的東西，就像【中國機長】里面，遇到飛行事故時，首先按照手冊，檢查一遍，排查原因，解決問題。
繼續
緊接著，又用 navicat 執行了修復表操作，結果返回了 Waiting for table metadata lock
當 MySQL 在進行一些 alter table 等 DDL 操作時，如果該表上有未提交的事務則會出現 Waiting for table metadata lock，而一旦出現 metadata lock，該表上的后續操作都會被阻塞。
解決辦法：
1、從 information_schema.innodb_trx 表中查看當前未提交的事務
select trx_state, trx_started, trx_mysql_thread_id, trx_query from information_schema.innodb_trxG
字段意義：
trx_state: 事務狀態，一般為 RUNNING
trx_started: 事務執行的起始時間，若時間較長，則要分析該事務是否合理
trx_mysql_thread_id: MySQL 的線程 ID，用于 kill
trx_query: 事務中的 sql
一般只要 kill 掉這些線程，DDL 操作就不會 Waiting for table metadata lock。
2、調整鎖超時閾值
lock_wait_timeout 表示獲取 metadata lock 的超時（單位為秒），允許的值范圍為 1 到 31536000（1 年）。 默認值為 31536000。
詳見 https://dev.mysql.com/doc/refman/5.6/en/se…
默認值為一年。。。。
將其調整為 30 分鐘
set Session lock_wait_timeout = 1800;
set global lock_wait_timeout = 1800;
好讓出現該問題時快速失敗（failfast）。
