kill 指令有兩種寫法 " kill query + 線程 id "、" kill connection(可缺省) + 線程 id "。分別表示關閉指定線程正在執行的語句、斷開指定線程連接的客戶端（如果有正在執行的操作會先停止執行的操作再關閉連接）。但某些情況下使用 kill query 后使用 show processlist 查看 Command 列為 killed（表示 正在等待回收線程回收，還未回收），這是為什么呢？

在解答這個問題前，需要知道服務器端處理請求的線程是如何執行的，以及 kill 命令是如何作用的。

Kill 指令執行原理

指令執行特點

1、 一個語句執行過程中有多處 " 埋點 "，在這些 " 埋點 " 的地方判斷線程狀態，如果發現線程狀態是 THD:KILL_QUERY，才開始進入語句終止邏輯；

2、如果處于等待狀態，必須是一個可以被喚醒的等待，否則根本不會執行到“埋點”處；

3、語句從開始進入終止邏輯，到終止邏輯完全完成，是有一個過程的。

kill query 執行原理

kill query 主要進行了兩步操作：

1、把線程的運行狀態改成 THD::KILL_QUERY(將變量 killed 賦值為 THD::KILL_QUERY)；

2、給會話的執行線程發一個信號，退出阻塞狀態，處理這個狀態。

Kill Connection 執行原理

1、把 12 號線程狀態設置為 KILL_CONNECTION；

2、關掉 12 號線程的網絡連接。

是否可以被中斷判斷

1、一般正常執行的語句在執行 kill query 后都會先將狀態從 killed 改成 KILL_QUERY，然后執行到 " 埋點 " 處被判斷中斷執行。

2、如果是處于阻塞的語句，那么需要去查看當前阻塞等待的狀態是否可以被喚醒，如果可以被喚醒才有機會中斷當前語句。

可以被中斷的場景：正常執行或者處于可以被喚醒的阻塞等待狀態。

因為等行鎖時，使用的是 pthread_cond_timedwait 函數，所以這個等待狀態可以被喚醒。可以被 kill query 直接喚醒繼續執行直到 "埋點" 判斷。

不可以被中斷的場景：被阻塞且不能被喚醒。

例子：因并發線程被使用完而造成的阻塞。

將參數 innodb_thread_concurrency（MySQL 的并發線程數）設為 2。然后執行下面的操作：

在 sessionD 執行 kill query C 后 sessionC 并沒有退出阻塞。

• 問題1：為什么使用 kill query 沒有中斷阻塞？

答：因為這種阻塞從微觀上來看并不是阻塞，而是一種循環判斷。每隔 10 毫秒判斷一下是否可以進入 Innodb 執行，如果不行，就調用 nanosleep 函數進入 sleep 狀態。也就是說，雖然線程的狀態已經被設置成了 KILL_QUERY（THD::KILL_QUERY），但是在這個等待進入 InnoDB 的循環過程中，并沒有執行到 "埋點"，也就沒有去判斷線程的狀態，因此根本不會進入終止邏輯階段。所以也就不會中斷。

• 問題2：如果此時使用 show processlist 來查看，會發現 Command 列為 killed，這是為什么？

答：kill query 語句會將線程狀態設為 KILL_QUERY ，這時會因為這個狀態而被判斷為正在執行中斷邏輯，所以 Command 值為 killed。

• 問題3：為什么使用 kill connection 可以中斷阻塞？

答：因為 kill connection 會直接關閉線程的網絡連接，強制關閉，所以這時候 session C 收到了斷開連接的提示。

• 問題4：如果只是使用 kill query 什么時候才能中斷阻塞？

答：只有等到會話被分配了線程后執行到 “ 埋點 ” 后判斷然后執行中斷邏輯才會退出。而被分配線程后并不是就一定會中斷，如果在執行到 "埋點" 之前讓出線程，那么就會再次等待。MySQL 的線程是多路復用的。

其他

1、其實除了上面使用 kill 命令來終止阻塞狀態外，還可以直接在該會話中使用 “ ctrl+c ” 來中止阻塞，這又是什么原理呢？

 答：首先要知道客戶端操作服務端是客戶端開啟一個線程，讓這個線程去處理，發送請求數據，通過網絡傳輸到服務端，服務端再分配線程去處理。而 "ctrl +c " 是讓客戶端另開一個連接，并發送一個 kill query 的命令。所以雖然我們看來是中斷了阻塞，但是處理上一個連接的服務端線程并一定就會被中斷。

2、為什么在指定庫名連接時會很慢？如下圖：

答：這是由于 MySQL 默認開啟了自動補全功能（輸入表名時可以使用 tab 自動補全）。其實現是在連接數據庫多執行一些操作：

1、執行 show databases；
2、切到 db1 庫，執行 show tables；
3、把這兩個命令的結果用于構建一個本地的哈希表。（最耗時）

這個功能可以在命令中加上 -A 關閉。同時使用 -quick 也可以關閉。但是使用 -quick 可能會使客戶端性能降低。這是為什么？這就要說到數據在服務器端與客戶端發送的流程了。

服務器線程執行流程

客戶端首先與服務器端驗證用戶名和密碼，通過后正式建立連接，然后客戶端發送請求，服務器端從線程池中取一個線程來處理。處理的過程：

1、獲取一行，寫到 net_buffer 中。這塊內存的大小是由參數 net_buffer_length 定義的，默認是 16k。
2、重復獲取行，直到 net_buffer 寫滿，調用網絡接口發出去。
3、如果發送成功，就清空 net_buffer，然后繼續取下一行，并寫入 net_buffer。
4、如果發送函數返回 EAGAIN 或 WSAEWOULDBLOCK，就表示本地網絡棧（socket send buffer）寫滿了，進入等待。直到網絡棧重新可寫，再繼續發送。

從上面的流程可以知道，如果一次要發送的數據量超過 socket send buffer 空間，那么就會拆分開來發送，并不會發生 " 內存打爆 " 的情況。由此我們可以知道，MySQL 是邊讀邊發的。

1、如果請求返回的數據量很大，那么在等待返回的過程中使用 show processlist 查看 State 列的值就會為 " Sending to client"，表示服務器端的網絡棧寫滿了。

這是因為 Sate 列值的變化是在查詢請求到達開始執行就會變為 " Sending data "，如果網絡棧寫滿發就會切換為 " Sending to client "，表示 " 正在等待客戶端接收結果 "。" Sending data " 可能處于線程執行過程中的任意階段，比如因為鎖而阻塞的場景。

2、如果 show processlist 的 State 列一直為 " Sending to Client "，那么可以

　　1）查看這條SQL，判斷是否可以優化，減少返回值。

　　2）將 net_buffer_length 設的大一些，來避免或者減少發送阻塞的時間。

客戶端執行流程

在開始客戶端會創建線程去連接服務器端，然后接收服務端返回的數據，客戶端接收服務器端返回的數據有兩種方式：

1、本地緩存。在本地開一片內存，先把結果存起來。如果用 API 開發，對應的就是 mysql_store_result 方法。建議在客戶端處理量大時使用本地緩存。可以使用 mysql -h$host -P$port -u$user -p$pwd -e "select * from db1.t" > $target_file 將返回的數據保存到指定文件。

2、不緩存，讀一個處理一個。如果用 API 開發，對應的就是 mysql_use_result 方法。

回到上面的問題，為什么使用 -quick 可能會導致客戶端性能下降？這是因為客戶端默認使用緩存來接收，所以在客戶端正在處理其他數據時就可以先進行緩存，等到后面直接讀取緩存就可以了。而使用 quick 就會使客戶端接收不使用緩存，那么如果客戶端正在執行其他操作這個數據就會被阻塞，并且服務器端對應的線程也會因為沒有收到客戶端的反饋而沒有中斷這次事務，這次事務涉及到的資源鎖也沒有釋放，造成并發問題，影響效率。除此之外， quick 還有三個效果。

1、就是前面提到的，跳過表名自動補全功能。
2、客戶端接收數據使用不緩存的方式。而 mysql_store_result 方法需要申請本地內存來緩存查詢結果，如果查詢結果太大，會耗費較多的本地內存，可能會影響客戶端本地機器的性能；
3、不會把執行命令記錄到本地的命令歷史文件。

以上就是詳解MySQL kill 指令的執行原理的詳細內容，更多關于MySQL kill 指令的資料請關注腳本之家其它相關文章！