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、不會把執行命令記錄到本地的命令歷史檔案。