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

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

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

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

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

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

kill query 執(zhí)行原理

kill query 主要進(jìn)行了兩步操作：

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

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

Kill Connection 執(zhí)行原理

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

2、關(guān)掉 12 號線程的網(wǎng)絡(luò)連接。

是否可以被中斷判斷

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

其他

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

客戶端執(zhí)行流程

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

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

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

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

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

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