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

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

Kill 指令執(zhí)行原理

指令執(zhí)行特點(diǎn)

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

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

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

kill query 執(zhí)行原理

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

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

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

Kill Connection 執(zhí)行原理

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

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

是否可以被中斷判斷

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

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

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

因?yàn)榈刃墟i時(shí)，使用的是 pthread_cond_timedwait 函數(shù)，所以這個(gè)等待狀態(tài)可以被喚醒?？梢员?kill query 直接喚醒繼續(xù)執(zhí)行直到 "埋點(diǎn)" 判斷。

不可以被中斷的場(chǎng)景：被阻塞且不能被喚醒。

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

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

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

• 問(wèn)題1：為什么使用 kill query 沒(méi)有中斷阻塞？

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

• 問(wèn)題2：如果此時(shí)使用 show processlist 來(lái)查看，會(huì)發(fā)現(xiàn) Command 列為 killed，這是為什么？

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

• 問(wèn)題3：為什么使用 kill connection 可以中斷阻塞？

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

• 問(wèn)題4：如果只是使用 kill query 什么時(shí)候才能中斷阻塞？

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

其他

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

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

2、為什么在指定庫(kù)名連接時(shí)會(huì)很慢？如下圖：

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

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

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

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

客戶端首先與服務(wù)器端驗(yàn)證用戶名和密碼，通過(guò)后正式建立連接，然后客戶端發(fā)送請(qǐng)求，服務(wù)器端從線程池中取一個(gè)線程來(lái)處理。處理的過(guò)程：

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ù)量超過(guò) socket send buffer 空間，那么就會(huì)拆分開來(lái)發(fā)送，并不會(huì)發(fā)生 " 內(nèi)存打爆 " 的情況。由此我們可以知道，MySQL 是邊讀邊發(fā)的。

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

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

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

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

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

客戶端執(zhí)行流程

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

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

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

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

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

以上就是詳解MySQL kill 指令的執(zhí)行原理的詳細(xì)內(nèi)容，更多關(guān)于MySQL kill 指令的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！