建站
咨詢
售后
建站咨詢
新聞中心
問題描述
您是否曾經(jīng)試圖殺死一個查詢，但它并沒有消失，而是在運(yùn)行的查詢中停留了很長一段時間？或者你注意到一些被標(biāo)記為被殺死的線程不時出現(xiàn)并且實際上并沒有死亡。這些僵尸線程是什么？為什么 MySQL 有時似乎無法快速終止查詢？本章對此問題進(jìn)行剖析。
成都創(chuàng)新互聯(lián)公司專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于網(wǎng)站設(shè)計、網(wǎng)站制作、臨沭網(wǎng)絡(luò)推廣、重慶小程序開發(fā)公司、臨沭網(wǎng)絡(luò)營銷、臨沭企業(yè)策劃、臨沭品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；成都創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供臨沭建站搭建服務(wù)，24小時服務(wù)熱線：13518219792，官方網(wǎng)址：www.cdcxhl.com
Threads and connections
MySQL 為每個客戶端連接使用單獨的線程。發(fā)送到 MySQL 的查詢由先前與查詢的連接關(guān)聯(lián)的線程處理。任何擁有足夠權(quán)限的人都可以通過運(yùn)行SHOW PROCESSLIST命令查看當(dāng)前活動線程的列表以及一些其他詳細(xì)信息，該命令返回一個類似表的視圖，每一行都是個連接。具體如下：
任何正在運(yùn)行的查詢或列表中的任何現(xiàn)有連接都可以使用KILL命令進(jìn)行終止。
命令語法：
KILL [QUERY | CONNECTION]
其中thread_id是來自進(jìn)程列表輸出的第一列的值?？蛇x參數(shù)是只運(yùn)行的查詢還是終止整個會話。它默認(rèn)為后者，因此不需要指定CONNECTION 。
運(yùn)行該命令實際上并沒有做任何事情，除了在所選線程內(nèi)設(shè)置一個特殊標(biāo)志。因此 kill 操作不會與相應(yīng)的 request 同步發(fā)生。在許多情況下，線程或查詢需要一些時間才能停止。在語句執(zhí)行的各個階段檢查標(biāo)志。它何時準(zhǔn)確發(fā)生或發(fā)生頻率如何，取決于線程實際正在執(zhí)行的工作。
例如：
- 在ALTER TABLE期間，當(dāng) MySQL 將數(shù)據(jù)重寫到新的臨時表中時，在從原始表中讀取每個行塊之前檢查它。在此過程中，臨時表被刪除，原始結(jié)構(gòu)保持不變。
- 對于UPDATE和DELETE，在每個更新或刪除的行之后還有一個額外的檢查。如果查詢注意到請求終止之前，進(jìn)行了任何更改，則必須回滾它們。注意：如果表的存儲引擎不支持事務(wù)（例如MyISAM），則更改無法回滾，因此該操作將導(dǎo)致部分更新！
- SELECT在讀取一行行后也會檢查它。
當(dāng)然，這些只是基本示例，不同情況下，可能會有所不同。在某些情況下，某些查詢甚至可能無法終止。從
INFORMATION_SCHEMA.INNODB_BUFFER_POOL_PAGES_INDEX表中讀取時發(fā)生過一次這種情況。數(shù)據(jù)庫當(dāng)時存在性能問題，查詢執(zhí)行基本上停止在 InnoDB 深處的某個鎖上，并且它再也沒有回到可以再次檢查標(biāo)志值的點上。
線程長時間處于終止?fàn)顟B(tài)。這是什么意思？
實際上，可以有兩種不同的情況。如果發(fā)出KILL
如果你看到這樣的東西怎么辦？
它可能是錯誤（例如錯誤#52528），或者更可能是數(shù)據(jù)庫在內(nèi)部執(zhí)行一些工作，以便任務(wù)終止后進(jìn)行清理。
當(dāng)然，沒有簡單的方法來確認(rèn)這是否是一個錯誤。因此，為了弄清楚它，您應(yīng)該尋找證明它不是錯誤的證據(jù)。您所看到的只是標(biāo)準(zhǔn)操作的效果，MySQL 在查詢或事務(wù)之后必須執(zhí)行該操作以進(jìn)行清理。
一個線程在被殺死或查詢結(jié)束的情況下停留更長時間的最常見原因可能是等待InnoDB 表上的事務(wù)回滾。這有時可能需要很長時間才能完成，尤其是當(dāng)必須刪除數(shù)十萬或數(shù)百萬的更改時。
如何驗證？
檢查是SHOW ENGINE INNODB STATUS\G的輸出。如果當(dāng)前正在進(jìn)行回滾，會有如下簡單的信息：
---TRANSACTION 0 10411, ACTIVE 28 sec, process no 15506, OS thread id 140732309711184 rollback
mysql tables in use 1, locked 1 ROLLING BACK 7585 lock struct(s), heap size 751600, undo log entries 798854
MySQL thread id 14 , query id 206 localhost root end
update testdb.sometable set cc=sqrt(id)
該示例顯示了如果一個線程被標(biāo)記為kill或query end，并且 InnoDB 引擎狀態(tài)報告同一線程的回滾，請等待它結(jié)束。
如果不是這樣呢？
它可能與從磁盤中刪除一些臨時表有關(guān)。一個ALTER TABLE可能需要丟棄一個非常大的臨時表，而在某些文件系統(tǒng)（例如ext3或ext4）上刪除大文件可能相當(dāng)慢，因此可能需要幾秒鐘甚至更長的時間。任何 DML 語句也可以創(chuàng)建臨時表，但通常不會那么大。
在最極端的情況下，刪除文件也不會超過十或二十秒，但在 I/O 負(fù)載較重的情況下，它可能會更長，所以有什么方法可以查看是否有臨時表是否被創(chuàng)造？在Percona Server或MariaDB中，您檢查INFORMATION_SCHEMA.GLOBAL_TEMPORARY_TABLE和INFORMATION_SCHEMA.TEMPORARY_TABLE的內(nèi)容。它僅適用于使用CREATE TEMPORARY TABLE語句手動建立的臨時表，不適用于 MySQL 隱式創(chuàng)建的執(zhí)行復(fù)雜查詢時的臨時表。
SESSION_ID與進(jìn)程列表中的線程標(biāo)識符相同，因此您可以殺死任何連接到臨時表的線程。
其他類型的臨時表不容易追蹤。有時可以在SHOW PROCESSLIST輸出中發(fā)現(xiàn)有用信息：
有時您可以檢查實例打開的臨時文件：
紅色標(biāo)記的值是文件的大小。這些可以幫助您定位正在刪除的臨時表。
結(jié)論
有時看到一個數(shù)據(jù)庫線程被殺死，但線程并沒有立即被終止，或者一個查詢似乎無法結(jié)束，這可能是正常的。因為實際操作不會與 kill 命令同步執(zhí)行，之后 MySQL可能仍需要一些時間才能正確清理。不管真正的原因是什么，如果不重新啟動數(shù)據(jù)庫，就不可能擺脫這種掛起的線程。也沒有辦法像Unix 系統(tǒng)中的kill -9
網(wǎng)站名稱：為什么線程有時會在MySQL中保持“killed”狀態(tài)？
網(wǎng)站網(wǎng)址：http://m.fisionsoft.com.cn/article/coossee.html
