MySql的kill命令

在 MySQL 中有兩個 kill 命令：

• 一個是 kill query + 線程 id，表示終止這個線程中正在執(zhí)行的語句；
• 一個是 kill connection + 線程 id，這里 connection 可缺省，表示斷開這個線程的連接，當然如果這個線程有語句正在執(zhí)行，也是要先停止正在執(zhí)行的語句的。

不知道你在使用 MySQL 的時候，有沒有遇到過這樣的現(xiàn)象：使用了 kill 命令，卻沒能斷開這個連接。再執(zhí)行 show processlist 命令，看到這條語句的 Command 列顯示的是 Killed。顯示為 Killed 是什么意思，不是應(yīng)該直接在 show processlist 的結(jié)果里看不到這個線程了嗎？

大多數(shù)情況下，kill query/connection 命令是有效的。比如，執(zhí)行一個查詢的過程中，發(fā)現(xiàn)執(zhí)行時間太久，要放棄繼續(xù)查詢，這時就可以用 kill query 命令，終止這條查詢語句。還有一種情況是，語句處于鎖等待的時候，直接使用 kill 命令也是有效的。

一起來看下這個例子：

可以看到，session C 執(zhí)行 kill query 以后，session B 幾乎同時就提示了語句被中斷。這，就是預(yù)期的結(jié)果。

一、收到 kill 以后，線程做什么？

但是，停下來想一下：session B 是直接終止掉線程，什么都不管就直接退出嗎？

顯然，這是不行的。在全局鎖和表鎖中，當對一個表做增刪改查操作時，會在表上加 MDL 讀鎖。所以，session B 雖然處于 blocked 狀態(tài)，但還是拿著一個 MDL 讀鎖的。

如果線程被 kill 的時候，就直接終止，那之后這個 MDL 讀鎖就沒機會被釋放了。這樣看來，kill 并不是馬上停止的意思，而是告訴執(zhí)行線程說，這條語句已經(jīng)不需要繼續(xù)執(zhí)行了，可以開始“執(zhí)行停止的邏輯了”。

其實，這跟 Linux 的 kill 命令類似，kill -N pid 并不是讓進程直接停止，而是給進程發(fā)一個信號，然后進程處理這個信號，進入終止邏輯。只是對于 MySQL 的 kill 命令來說，不需要傳信號量參數(shù)，就只有“停止”這個命令。

實現(xiàn)上，當用戶執(zhí)行 kill query thread_id_B 時，MySQL 里處理 kill 命令的線程做了兩件事：

• 把 session B 的運行狀態(tài)改成 THD::KILL_QUERY(將變量 killed 賦值為 THD::KILL_QUERY)；
• 給 session B 的執(zhí)行線程發(fā)一個信號。

為什么要發(fā)信號呢？因為像圖 1 的例子里面，session B 處于鎖等待狀態(tài)，如果只是把 session B 的線程狀態(tài)設(shè)置 THD::KILL_QUERY，線程 B 并不知道這個狀態(tài)變化，還是會繼續(xù)等待。

發(fā)一個信號的目的，就是讓 session B 退出等待，來處理這個 THD::KILL_QUERY 狀態(tài)。

上面的分析中，隱含了這么三層意思：

• 一個語句執(zhí)行過程中有多處“埋點”，在這些“埋點”的地方判斷線程狀態(tài)，如果發(fā)現(xiàn)線程狀態(tài)是 THD::KILL_QUERY，才開始進入語句終止邏輯；
• 如果處于等待狀態(tài)，必須是一個可以被喚醒的等待，否則根本不會執(zhí)行到“埋點”處；
• 語句從開始進入終止邏輯，到終止邏輯完全完成，是有一個過程的。

到這里原來不是“說停就停的”。

看一個 kill 不掉的例子，也就是在MySQL 實例健康狀態(tài)檢測方法中提到的 innodb_thread_concurrency 不夠用的例子。

首先，執(zhí)行 set global innodb_thread_concurrency=2，將 InnoDB 的并發(fā)線程上限數(shù)設(shè)置為 2；

然后，執(zhí)行下面的序列：

可以看到：

1. sesssion C 執(zhí)行的時候被堵住了；
2. 但是 session D 執(zhí)行的 kill query C 命令卻沒什么效果，
3. 直到 session E 執(zhí)行了 kill connection 命令，才斷開了 session C 的連接，提示“Lost connection to MySQL server during query”，
4. 但是這時候，如果在 session E 中執(zhí)行 show processlist，你就能看到下面這個圖。

這時候，id=12 這個線程的 Commnad 列顯示的是 Killed。也就是說，客戶端雖然斷開了連接，但實際上服務(wù)端上這條語句還在執(zhí)行過程中。為什么在執(zhí)行 kill query 命令時，這條語句不像第一個例子的 update 語句一樣退出呢？

在實現(xiàn)上，等行鎖時，使用的是 pthread_cond_timedwait 函數(shù)，這個等待狀態(tài)可以被喚醒。

但是，在這個例子里，12 號線程的等待邏輯是這樣的：每 10 毫秒判斷一下是否可以進入 InnoDB 執(zhí)行，如果不行，就調(diào)用 nanosleep 函數(shù)進入 sleep 狀態(tài)。

也就是說，雖然 12 號線程的狀態(tài)已經(jīng)被設(shè)置成了 KILL_QUERY，但是在這個等待進入 InnoDB 的循環(huán)過程中，并沒有去判斷線程的狀態(tài)，因此根本不會進入終止邏輯階段。

而當 session E 執(zhí)行 kill connection 命令時，是這么做的，

• 把 12 號線程狀態(tài)設(shè)置為 KILL_CONNECTION；
• 關(guān)掉 12 號線程的網(wǎng)絡(luò)連接。因為有這個操作，所以你會看到，這時候 session C 收到了斷開連接的提示。

那為什么執(zhí)行 show processlist 的時候，會看到 Command 列顯示為 killed 呢？

其實，這就是因為在執(zhí)行 show processlist 的時候，有一個特別的邏輯：

如果一個線程的狀態(tài)是KILL_CONNECTION，就把Command列顯示成Killed。

所以其實，即使是客戶端退出了，這個線程的狀態(tài)仍然是在等待中。那這個線程什么時候會退出呢？答案是，只有等到滿足進入 InnoDB 的條件后，session C 的查詢語句繼續(xù)執(zhí)行，然后才有可能判斷到線程狀態(tài)已經(jīng)變成了 KILL_QUERY 或者 KILL_CONNECTION，再進入終止邏輯階段。

小結(jié)一下。這個例子是 kill 無效的第一類情況，即：線程沒有執(zhí)行到判斷線程狀態(tài)的邏輯。跟這種情況相同的，還有由于 IO 壓力過大，讀寫 IO 的函數(shù)一直無法返回，導(dǎo)致不能及時判斷線程的狀態(tài)。

另一類情況是，終止邏輯耗時較長。這時候，從 show processlist 結(jié)果上看也是 Command=Killed，需要等到終止邏輯完成，語句才算真正完成。這類情況，比較常見的場景有以下幾種：

1. 超大事務(wù)執(zhí)行期間被 kill。這時候，回滾操作需要對事務(wù)執(zhí)行期間生成的所有新數(shù)據(jù)版本做回收操作，耗時很長。大查詢回滾。如果查詢過程中生成了比較大的臨時文件，加上此時文件系統(tǒng)壓力大，刪除臨時文件可能需要等待 IO 資源，導(dǎo)致耗時較長。
2. DDL 命令執(zhí)行到最后階段，如果被 kill，需要刪除中間過程的臨時文件，也可能受 IO 資源影響耗時較久。

如果直接在客戶端通過 Ctrl+C 命令，是不是就可以直接終止線程呢？答案是，不可以。

這里有一個誤解，其實在客戶端的操作只能操作到客戶端的線程，客戶端和服務(wù)端只能通過網(wǎng)絡(luò)交互，是不可能直接操作服務(wù)端線程的。而由于 MySQL 是停等協(xié)議，所以這個線程執(zhí)行的語句還沒有返回的時候，再往這個連接里面繼續(xù)發(fā)命令也是沒有用的。

實際上，執(zhí)行 Ctrl+C 的時候，是 MySQL 客戶端另外啟動一個連接，然后發(fā)送一個 kill query 命令。所以，可別以為在客戶端執(zhí)行完 Ctrl+C 就萬事大吉了。

因為，要 kill 掉一個線程，還涉及到后端的很多操作。

二、另外兩個關(guān)于客戶端的誤解

1、如果庫里面的表特別多，連接就會很慢。

有些線上的庫，會包含很多表（我見過最多的一個庫里有 6 萬個表）。

每次用客戶端連接都會卡在下面這個界面上。

而如果 db1 這個庫里表很少的話，連接起來就會很快，可以很快進入輸入命令的狀態(tài)。因此，有同學(xué)會認為是表的數(shù)目影響了連接性能。每個客戶端在和服務(wù)端建立連接的時候，需要做的事情就是 TCP 握手、用戶校驗、獲取權(quán)限。但這幾個操作，顯然跟庫里面表的個數(shù)無關(guān)。

但實際上，正如圖中的文字提示所說的，當使用默認參數(shù)連接的時候，MySQL 客戶端會提供一個本地庫名和表名補全的功能。

為了實現(xiàn)這個功能，客戶端在連接成功后，需要多做一些操作：

• 執(zhí)行 show databases；
• 切到 db1 庫，執(zhí)行 show tables；
• 把這兩個命令的結(jié)果用于構(gòu)建一個本地的哈希表。

在這些操作中，最花時間的就是第三步在本地構(gòu)建哈希表的操作。所以，當一個庫中的表個數(shù)非常多的時候，這一步就會花比較長的時間。也就是說，感知到的連接過程慢，其實并不是連接慢，也不是服務(wù)端慢，而是客戶端慢。

圖中的提示也說了，如果在連接命令中加上 -A，就可以關(guān)掉這個自動補全的功能，然后客戶端就可以快速返回了。

這里自動補全的效果就是，你在輸入庫名或者表名的時候，輸入前綴，可以使用 Tab 鍵自動補全表名或者顯示提示。

實際使用中，如果你自動補全功能用得并不多，建議每次使用的時候都默認加 -A。

2、加–quick(或者簡寫為 -q) 參數(shù)，也可以跳過這個階段

但是，這個–quick 是一個更容易引起誤會的參數(shù)，也是關(guān)于客戶端常見的一個誤解。

設(shè)置了這個參數(shù)可能會降低服務(wù)端的性能。為什么這么說呢？MySQL 客戶端發(fā)送請求后，接收服務(wù)端返回結(jié)果的方式有兩種：

• 一種是本地緩存，也就是在本地開一片內(nèi)存，先把結(jié)果存起來。如果你用 API 開發(fā)，對應(yīng)的就是 mysql_store_result 方法。
• 另一種是不緩存，讀一個處理一個。如果你用 API 開發(fā)，對應(yīng)的就是 mysql_use_result 方法。

MySQL 客戶端默認采用第一種方式，而如果加上–quick 參數(shù)，就會使用第二種不緩存的方式。

采用不緩存的方式時，如果本地處理得慢，就會導(dǎo)致服務(wù)端發(fā)送結(jié)果被阻塞，因此會讓服務(wù)端變慢。

為什么要給這個參數(shù)取名叫作 quick 呢？

這是因為使用這個參數(shù)可以達到以下三點效果：

• 第一點，跳過表名自動補全功能。
• 第二點，mysql_store_result 需要申請本地內(nèi)存來緩存查詢結(jié)果，如果查詢結(jié)果太大，會耗費較多的本地內(nèi)存，可能會影響客戶端本地機器的性能；
• 第三點，是不會把執(zhí)行命令記錄到本地的命令歷史文件。

–quick 參數(shù)的意思，是讓客戶端變得更快。

三、總結(jié)

這些“kill 不掉”的情況，其實是因為發(fā)送 kill 命令的客戶端，并沒有強行停止目標線程的執(zhí)行，而只是設(shè)置了個狀態(tài)，并喚醒對應(yīng)的線程。而被 kill 的線程，需要執(zhí)行到判斷狀態(tài)的“埋點”，才會開始進入終止邏輯階段。

并且，終止邏輯本身也是需要耗費時間的。所以，如果發(fā)現(xiàn)一個線程處于 Killed 狀態(tài)，可以做的事情就是，通過影響系統(tǒng)環(huán)境，讓這個 Killed 狀態(tài)盡快結(jié)束。比如，如果是第一個例子里 InnoDB 并發(fā)度的問題，就可以臨時調(diào)大 innodb_thread_concurrency 的值，或者停掉別的線程，讓出位子給這個線程執(zhí)行。而如果是回滾邏輯由于受到 IO 資源限制執(zhí)行得比較慢，就通過減少系統(tǒng)壓力讓它加速。

做完這些操作后，其實已經(jīng)沒有辦法再對它做什么了，只能等待流程自己完成。

如果你碰到一個被 killed 的事務(wù)一直處于回滾狀態(tài)，你認為是應(yīng)該直接把 MySQL 進程強行重啟，還是應(yīng)該讓它自己執(zhí)行完成呢？為什么呢？

1. 等。死等。 重啟依然需要回滾完之后，重啟才能完成。
2. 若影響了其他線程，可以進行主備切換。

到此這篇關(guān)于關(guān)于MySql的kill命令詳解的文章就介紹到這了,更多相關(guān)MySql的kill命令內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論