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

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

Kill 指令執(zhí)行原理指令執(zhí)行特點

1、 一個語句執(zhí)行過程中有多處 ' 埋點 '，在這些 ' 埋點 ' 的地方判斷線程狀態(tài)，如果發(fā)現(xiàn)線程狀態(tài)是 THD:KILL_QUERY，才開始進入語句終止邏輯；

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

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

kill query 執(zhí)行原理

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

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

2、給會話的執(zhí)行線程發(fā)一個信號，退出阻塞狀態(tài)，處理這個狀態(tài)。

Kill Connection 執(zhí)行原理

1、把 12 號線程狀態(tài)設置為 KILL_CONNECTION；

2、關掉 12 號線程的網(wǎng)絡連接。

是否可以被中斷判斷

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

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

可以被中斷的場景：正常執(zhí)行或者處于可以被喚醒的阻塞等待狀態(tài)。

因為等行鎖時，使用的是 pthread_cond_timedwait 函數(shù)，所以這個等待狀態(tài)可以被喚醒。可以被 kill query 直接喚醒繼續(xù)執(zhí)行直到 '埋點' 判斷。

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

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

將參數(shù) innodb_thread_concurrency（MySQL 的并發(fā)線程數(shù)）設為 2。然后執(zhí)行下面的操作：

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

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

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

問題2：如果此時使用 show processlist 來查看，會發(fā)現(xiàn) Command 列為 killed，這是為什么？

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

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

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

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

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

其他

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

答：首先要知道客戶端操作服務端是客戶端開啟一個線程，讓這個線程去處理，發(fā)送請求數(shù)據(jù)，通過網(wǎng)絡傳輸?shù)椒斩耍斩嗽俜峙渚€程去處理。而 'ctrl +c ' 是讓客戶端另開一個連接，并發(fā)送一個 kill query 的命令。所以雖然我們看來是中斷了阻塞，但是處理上一個連接的服務端線程并一定就會被中斷。

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

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

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

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

服務器線程執(zhí)行流程

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

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

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

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

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

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

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

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

客戶端執(zhí)行流程

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

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

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

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

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

以上就是詳解MySQL kill 指令的執(zhí)行原理的詳細內(nèi)容，更多關于MySQL kill 指令的資料請關注好吧啦網(wǎng)其它相關文章！