MySQL神器之show full processlist

今天在同步測試資料時，網子突然斷了，等到重連之後，發現表打不開了。

可以看到表格的資料長度已有 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 processlist\G;
*************************** 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_schesche.

#欄位意義：

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）。

推薦教學：《MySQL教學》《Navicat》

以上是MySQL神器之show full processlist的詳細內容。更多資訊請關注PHP中文網其他相關文章！