mysql show full processlist 查看當前線程處理情況
事發現場每次執行看到的結果應該都有變化,因為是實時的,所以我定義為:「事發現場」,每次執行就相當於現場的快照
一般用到 show processlist 或 show full processlist 都是為了查看當前 mysql 是否有壓力,都在跑什麼語句,當前語句耗時多久了,有沒有什麼慢 SQL 正在執行之類的
可以看到總共有多少連結數,哪些線程有問題(time是執行秒數,時間長的就應該多注意了),然後可以把有問題的線程 kill 掉,這樣可以臨時解決一些突發性的問題
有時候一個快照可能看不出什麼問題,那麼可以頻發的刷新試試
問題排查show full processlist 可以看到所有連結的情況,但是大多連結的 state 其實是 Sleep 的,這種的其實是空閒狀態,沒有太多查看價值
我們要觀察的是有問題的,所以可以進行過濾:
select id, db, user, host, command, time, state, infofrom information_schema.processlistwhere command != 'Sleep'order by time desc這樣就過濾出來哪些是正在幹活的,然後按照消耗時間倒敘展示,排在最前面的,極大可能就是有問題的連結了,然後查看 info 一列,就能看到具體執行的什麼 SQL 語句了,針對分析
展示列解釋:
id - 線程ID,可以用:kill id; 殺死一個線程,很有用
db - 資料庫
user - 用戶
host - 連庫的主機IP
command - 當前執行的命令,比如最常見的:Sleep,Query,Connect 等
time - 消耗時間,單位秒,很有用
state - 執行狀態,比如:Sending data,Sorting for group,Creating tmp table,Locked等等,很有用,其他狀態可以看看本文最後的參考文章
info - 執行的SQL語句,很有用
kill 使用上面提到的 線程ID 是可以通過 kill 殺死的;所以上面基本上可以把有問題的執行語句找出來,然後就可以 kill 掉了,那麼一個一個來 kill 麼?
select concat('kill ', id, ';')from information_schema.processlistwhere command != 'Sleep'and time > 2*60order by time desc在下一步我就不用說了吧,把拼接 kill 的執行結果跑一遍就搞定了
這個有時候非常好用,誰用誰知道
常見問題一些問題會導致連鎖反應,而且不太好定位,有時候以為是慢查詢,很可能是大多時間是在等在CPU、內存資源的釋放,所以有時候同一個查詢消耗的時間有時候差異很大
總結了一些常見問題:
CPU報警:很可能是 SQL 裡面有較多的計算導致的
連接數超高:很可能是有慢查詢,然後導致很多的查詢在排隊,排查問題的時候可以看到」事發現場「類似的 SQL 語句一大片,那麼有可能是沒有索引或者索引不好使,可以用:explain 分析一下 SQL 語句