MySQL線程狀態(tài)的示例分析

這篇文章主要介紹了MySQL線程狀態(tài)的示例分析，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

文章目錄

• 
  

• 一、show processlist

• 二、command命令類型

• 三、用戶線程狀態(tài)

• 四、dump線程狀態(tài)

• 五、IO線程狀態(tài)

• 六、SQL 線程狀態(tài)

• 七、 主從連接線程狀態(tài)

• 八、事件調(diào)度線程狀態(tài)

一、show processlist

• Id：連接進(jìn)程標(biāo)識(shí)符。是由 CONNECTION_ID() 函數(shù)返回的值

• User：執(zhí)行語(yǔ)句的 MySQL 用戶名稱。如果顯示的是“system user”，它指的是由MySQL生成的非客戶端線程正在執(zhí)行內(nèi)部任務(wù)。例如主備復(fù)制中從
  庫(kù)上使用的 I/O 或 SQL 線程或延遲行處理程序的線程。“unauthenticated user”指的是客戶端已經(jīng)和服務(wù)端建立了 TCP/IP 連接但是還沒(méi)有對(duì)客戶端的用戶進(jìn)行用戶密碼認(rèn)證的線程。“event_scheduler”是指監(jiān)視計(jì)劃任務(wù)調(diào)度事件的線程。

• Host：執(zhí)行語(yǔ)句的客戶端的主機(jī)名，以 host_name：client_port顯示 (如果啟用了 skip_name_resolve 參數(shù)，則顯示為 ip:client_port 格式)

• Db：客戶端連接的默認(rèn)數(shù)據(jù)庫(kù)（如果連接時(shí)指定了庫(kù)名），否則顯示為 NULL 。

• Command：線程正在執(zhí)行的命令的類型。

• Time：線程處于當(dāng)前狀態(tài)的時(shí)間數(shù)（以秒為單位）。對(duì)于從庫(kù) SQL 線程，該值是最后復(fù)制事件的時(shí)間和從庫(kù)的實(shí)際時(shí)間之間的秒數(shù)。

• State：提示線程正在做什么樣的操作，事件或狀態(tài)。

• Info：線程正在執(zhí)行的語(yǔ)句。

二、command命令類型

• Binlog Dump：主庫(kù)線程用于將二進(jìn)制日志內(nèi)容發(fā)送到從庫(kù)

• Change user：線程正在執(zhí)行更改用戶操作

• Close stmt：線程正在關(guān)閉一個(gè)預(yù)編譯好的語(yǔ)句

• Connect：從庫(kù)線程已經(jīng)連接到主庫(kù)

• Connect Out：從庫(kù)正在連接到主庫(kù)

• Create DB：線程正在執(zhí)行一個(gè)建庫(kù)操作

• Daemon：這個(gè)是 server 內(nèi)部線程，不是客戶端連接的線程

• Debug：線程正在生成調(diào)試信息

• Delayed insert：是一個(gè)延遲插入處理程序的線程

• Drop DB：線程正在執(zhí)行 drop database 操作

• Execute：線程正在執(zhí)行一個(gè)預(yù)編譯好的語(yǔ)句

• Fetch：線程正在執(zhí)行語(yǔ)句并從中獲取結(jié)果集

• Field List：線程正在檢索表列的信息

• Init DB：線程正在選擇默認(rèn)數(shù)據(jù)庫(kù)

• Kill：線程正在殺死其他線程

• Long Data：線程在執(zhí)行語(yǔ)句并從中檢索并返回長(zhǎng)字段（大字段）類型的數(shù)據(jù)結(jié)果集

• Ping：線程正在處理服務(wù)器 ping 請(qǐng)求

• Prepare：線程正在執(zhí)行預(yù)編譯一個(gè)語(yǔ)句

• Processlist：線程正在生成有關(guān) server 線程的信息

• Query：線程正在執(zhí)行查詢語(yǔ)句

• Quit：線程正在終止

• Refresh：線程正在刷新表，日志或高速緩存，或重置狀態(tài)變量或復(fù)制 server 信息

• Register Slave：線程正在主庫(kù)上注冊(cè)從庫(kù)

• Reset stmt：線程正在重置預(yù)編譯語(yǔ)句

• Set option：線程正在設(shè)置或重置客戶端語(yǔ)句執(zhí)行選項(xiàng)

• Shutdown：線程正在執(zhí)行關(guān)閉 server

• Sleep：線程正在等待客戶端向其發(fā)送一個(gè)新語(yǔ)句請(qǐng)求

• Statistics：線程正在生成 server 狀態(tài)信息

• Table Dump：線程正在將表內(nèi)容發(fā)送到從庫(kù)

三、用戶線程狀態(tài)

• After create：當(dāng)線程創(chuàng)建一個(gè)表完成時(shí)（包括內(nèi)部臨時(shí)表），會(huì)出現(xiàn)這種狀態(tài)。
  即使由于某些錯(cuò)誤而導(dǎo)致創(chuàng)建表最終出錯(cuò)，也會(huì)出現(xiàn)此狀態(tài)

• Analyzing：線程正在 ANALYZE TABLE

• checking permissions：正在 server 中檢查線程是否具有執(zhí)行語(yǔ)句所需的權(quán)限

• Checking table：線程正在執(zhí)行表檢查操作

• cleaning up：線程已經(jīng)執(zhí)行完成了一個(gè)命令，并準(zhǔn)備釋放所占用的內(nèi)存和重置某些狀態(tài)變量

• closing tables：線程正在將表發(fā)生更改的數(shù)據(jù)刷新到磁盤(pán)并關(guān)閉表。

• converting HEAP to MyISAM：線程正在將內(nèi)部臨時(shí)表從 MEMORY 引擎表轉(zhuǎn)換為磁盤(pán) MyISAM 引擎的臨時(shí)表

• copy to tmp table：線程正在執(zhí)行 ALTER TABLE 語(yǔ)句。此狀態(tài)發(fā)生在新結(jié)構(gòu)的表已經(jīng)創(chuàng)建好之后，執(zhí)行 copy 舊表數(shù)據(jù)到新表中之前出現(xiàn)

• Copying to group table：如果語(yǔ)句使用了不同的 ORDER BY 和 GROUP BY 條件列，則按照 group by 對(duì)這些行數(shù)據(jù)進(jìn)行排序，并將排序結(jié)果復(fù)制到臨時(shí)表

• Copying to tmp table：server 正在復(fù)制數(shù)據(jù)到內(nèi)存臨時(shí)表

• altering table：server 正在執(zhí)行 in-place 的 ALTER TABLE 的過(guò)程

• Copying to tmp table on disk：server 正在復(fù)制數(shù)據(jù)到磁盤(pán)臨時(shí)表。因?yàn)榕R時(shí)結(jié)果集太大，所以，線程正在將內(nèi)存臨時(shí)表轉(zhuǎn)換為基于磁盤(pán)的臨時(shí)表，以節(jié)省內(nèi)存

• Creating index：線程正在執(zhí)行一個(gè) ALTER TABLE … ENABLE KEYS 語(yǔ)句

• Creating sort index：線程正在執(zhí)行 SELECT 且使用到了內(nèi)部臨時(shí)表

• creating table：線程正在創(chuàng)建表。包括創(chuàng)建臨時(shí)表時(shí)也會(huì)使用此狀態(tài)

• Creating tmp table：線程正在內(nèi)存或磁盤(pán)上創(chuàng)建一個(gè)臨時(shí)表。如果表在內(nèi)存中創(chuàng)建，但后來(lái)被轉(zhuǎn)換為磁盤(pán)表，則該操作期間的狀態(tài)將為“Copying to tmp table on disk”

• committing alter table to storage engine：server 已執(zhí)行完成 in-place 算法的 ALTER TABLE 語(yǔ)句，正在提交

• deleting from main table：server 正在執(zhí)行多表刪除語(yǔ)句中的第一部分?？吹竭@個(gè)
  狀態(tài)表示正在從第一個(gè)表中刪除，并保存后續(xù)用于刪除其他表的列數(shù)據(jù)和偏移量

• deleting from reference tables：server 正在執(zhí)行多表刪除語(yǔ)句的第二部分，從其他表中刪除匹配的行

• discard_or_import_tablespace ：線程正在執(zhí)行 ALTER TABLE … DISCARD TABLESPACE 或 ALTER TABLE … IMPORT TABLESPACE 語(yǔ)句

• end：這發(fā)生在語(yǔ)句執(zhí)行結(jié)束時(shí)，但在清除 ALTER TABLE，CREATE VIEW，DELETE，INSERT，SELECT 或 UPDATE 語(yǔ)句之前出現(xiàn)該狀態(tài)

• executing：線程正在執(zhí)行語(yǔ)句中

• Execution of init_command：線程正在執(zhí)行一個(gè)初始化系統(tǒng)變量的語(yǔ)句

• freeing items：線程已經(jīng)執(zhí)行完成了一個(gè)命令。釋放一些涉及到 query cache 狀態(tài)
  的 items。這種狀態(tài)后通常緊隨 cleaning up 狀態(tài)之后

• FULLTEXT initialization：server 正在準(zhǔn)備執(zhí)行自然語(yǔ)言全文搜索

• init：這在 ALTER TABLE，DELETE，INSERT，SELECT 或 UPDATE 語(yǔ)句初始化之前發(fā)生的狀態(tài)。server 在此狀態(tài)下執(zhí)行的操作包括刷新二進(jìn)制日志，InnoDB 日志和一些查詢緩存清理操作。對(duì)于這個(gè)狀態(tài)結(jié)束時(shí)，可能會(huì)有如下一些操作：
  當(dāng)表中的數(shù)據(jù)更改后刪除查詢緩存條目
  將事件寫(xiě)入二進(jìn)制日志
  釋放內(nèi)存緩沖區(qū)，包括 blob

• Killed：向線程發(fā)起一個(gè) kill 操作，線程應(yīng)該執(zhí)行終止操作。在 MySQL 的每個(gè)主循環(huán)中檢查線程的 kill 標(biāo)志，但在某些情況下，殺死線程可能只需要很短的時(shí)間。但如果被 kill 的線程被其他線程鎖定，則需要等待其他線程釋放鎖之后，kill 命令才會(huì)生效并執(zhí)行。

• logging slow query：線程正在向慢查詢?nèi)罩緦?xiě)一條語(yǔ)句

• login：連接線程的初始狀態(tài)，直到客戶端成功通過(guò)身份驗(yàn)證

• manage keys：server 正在啟用或禁用表索引

• NULL：此狀態(tài)用于 SHOW PROCESSLIST 語(yǔ)句

• Opening tables：線程正嘗試打開(kāi)一個(gè)表。打開(kāi)表操作應(yīng)該非?？欤谴蜷_(kāi)操作被阻止。例如，ALTER TABLE 或 LOCK TABLE 語(yǔ)句可以防止打開(kāi)表，直到該語(yǔ)句完成。另外也可能是 table_open_cache 不夠大導(dǎo)致不能打開(kāi)表。

• optimizing：server 正在對(duì)查詢執(zhí)行初始優(yōu)化

• preparing：此狀態(tài)發(fā)生在查詢優(yōu)化期間

• Purging old relay logs：線程正在刪除不需要的中繼日志文件

• query end：此狀態(tài)出現(xiàn)在執(zhí)行查詢語(yǔ)句之后但在釋放該查詢語(yǔ)句相關(guān)狀態(tài) items 之前

• Reading from net：server 正在從網(wǎng)絡(luò)讀取數(shù)據(jù)包。在 MySQL 5.7.8 之后該狀態(tài)叫做“Receiving from client” - Receiving from client：server 正在從客戶端讀取數(shù)據(jù)包。在 MySQL 5.7.8 叫做“Reading from net”

• Removing duplicates：查詢使用 SELECT DISTINCT 語(yǔ)句時(shí)，使 MySQL 無(wú)法在早期階段優(yōu)化掉 distinct 操作。因此，MySQL 需要一個(gè)額外的階段來(lái)刪除所有重復(fù)的行，然后將結(jié)果發(fā)送到客戶端

• removing tmp table：線程在 SELECT 語(yǔ)句執(zhí)行完成后，正在刪除內(nèi)部臨時(shí)表。如果 SELECT 語(yǔ)句未創(chuàng)建臨時(shí)表，則不會(huì)出現(xiàn)此狀態(tài)

• rename：線程正在執(zhí)行 rename 語(yǔ)句重命名表

• rename result table：線程正在執(zhí)行 ALTER TABLE 語(yǔ)句重命名表，已經(jīng)創(chuàng)建完成新表，并正在使用新表替換舊表名稱

• Reopen tables：線程獲得了表鎖，但是獲得鎖后，發(fā)現(xiàn)基礎(chǔ)表結(jié)構(gòu)已經(jīng)被改變了。
  于是釋放表鎖，并關(guān)閉表，嘗試重新打開(kāi)表

• Repair by sorting：修復(fù)代碼正在使用排序來(lái)創(chuàng)建索引

• preparing for alter table：server 正在準(zhǔn)備執(zhí)行 in-place 算法的 ALTER TABLE 語(yǔ) 句 - Repair done：該線程已完成 MyISAM 表的多線程修復(fù)

• Repair with keycache：修復(fù)代碼正在使用通過(guò) key cache 逐個(gè)創(chuàng)建 key 的方法修復(fù)索引。這比通過(guò)排序索引修復(fù)的方法慢得多

• Rolling back：線程正在回滾事務(wù)

• Saving state：對(duì)于 MyISAM 表操作（如修復(fù)或分析），線程正在將新表狀態(tài)保存到.MYI 文件頭。狀態(tài)包括：表數(shù)據(jù)行數(shù),AUTO_INCREMENT 計(jì)數(shù)器和 key
  分布之類的信息

• Searching rows for update：線程正在進(jìn)行第一階段查找所有匹配的行，然后再更新它們。如果 UPDATE 正在更改用于查找涉及的行的索引，則必須先把 update 滿足匹配的行先查找出來(lái)

• Sending data：線程正在讀取和處理 SELECT 語(yǔ)句產(chǎn)生的數(shù)據(jù)行，并將數(shù)據(jù)發(fā)送到客戶端。因?yàn)樵诖藸顟B(tài)期間發(fā)生的操作可能產(chǎn)生大量的磁盤(pán)訪問(wèn)（讀?。?，所以它通常是給定查詢的生存期內(nèi)最長(zhǎng)的運(yùn)行狀態(tài)

• Sending to client：server 正在向客戶端寫(xiě)入數(shù)據(jù)包。在 MySQL 5.7.8 之前叫做“Writing to net”

• setup：線程正在執(zhí)行 ALTER TABLE 操作

• Sorting for group：線程正在執(zhí)行一個(gè) GROUP BY 排序操作

• Sorting for order：線程正在執(zhí)行一個(gè) ORDER BY 排序操作

• Sorting index：線程正在排序索引頁(yè)面，以便在 MyISAM 表優(yōu)化操作期間實(shí)現(xiàn)更高效的訪問(wèn)

• Sorting result：對(duì)于 SELECT 語(yǔ)句，這類似“Creating sort index”狀態(tài)，但是針對(duì)于非臨時(shí)表

• statistics：server 正在計(jì)算統(tǒng)計(jì)信息以優(yōu)化查詢執(zhí)行計(jì)劃。如果一個(gè)線程在這個(gè)狀態(tài)很長(zhǎng)一段時(shí)間，server 可能是磁盤(pán)執(zhí)行其他工作而阻塞了統(tǒng)計(jì)信息的操作，也有可能發(fā)生了鎖等待。

• System lock：線程調(diào)用了mysql_lock_tables()，線程狀態(tài)從未更新過(guò)。這是一個(gè)非常常見(jiàn)的狀態(tài)，出現(xiàn)該狀態(tài)的原因有很多。例如，線程將請(qǐng)求或正在等待表的內(nèi)部或外部系統(tǒng)鎖定。當(dāng) InnoDB 在執(zhí)行 LOCK TABLES 期間等待表級(jí)鎖時(shí)，可能會(huì)發(fā)生這種情況。如果此狀態(tài)是由外部鎖請(qǐng)求引起的，如果您不使用多個(gè)mysqld 服務(wù)器訪問(wèn)同一 MyISAM 表，則可以使用–skip-external-locking 選項(xiàng)禁用外部系統(tǒng)鎖。但是，默認(rèn)情況下外部鎖定是禁用的，因此此選項(xiàng)可能無(wú)效。
  對(duì)于 SHOW PROFILE，此狀態(tài)表示線程正在請(qǐng)求鎖定

• update：線程準(zhǔn)備開(kāi)始更新表

• Updating：線程搜索且正在更新數(shù)據(jù)行

• updating main table：server 正在執(zhí)行多表更新語(yǔ)句的第一部分。該狀態(tài)表示正在
  更新第一個(gè)表，并保存列值和偏移量以用于更新其他（引用）表

• updating reference tables：server 正在執(zhí)行多表更新語(yǔ)句的第二部分，更新其他表
  的匹配行

• User lock：線程將請(qǐng)求或正在等待通過(guò) GET_LOCK() 調(diào)用請(qǐng)求的建議鎖。對(duì)于SHOW PROFILE，此狀態(tài)表示線程正在請(qǐng)求鎖定（無(wú)需等待）

• User sleep：線程已調(diào)用 SLEEP() 調(diào)用

• Waiting for commit lock：FLUSH TABLES WITH READ LOCK 語(yǔ)句正在獲取提交鎖

• Waiting for global read lock：FLUSH TABLES WITH READ LOCK 正在等待獲取全局讀鎖或全局 read_only 系統(tǒng)變量設(shè)置

• Waiting for tables：線程獲取到一個(gè)通知，表的底層結(jié)構(gòu)已經(jīng)改變，它需要重新打開(kāi)表以獲得新的結(jié)構(gòu)。但是，要重新打開(kāi)表，它必須等待，直到所有其他線
  程都關(guān)閉了舊數(shù)據(jù)結(jié)構(gòu)的表的訪問(wèn)。如果另一個(gè)線程已在表中使用 FLUSH TABLES 或下列語(yǔ)句之一，則就會(huì)出現(xiàn)這個(gè)通知：

• FLUSH TABLES tbl_name

• ALTER TABLE

• RENAME TABLE * REPAIR TABLE

• ANALYZE TABLE

• OPTIMIZE TABLE

• Waiting for table flush：線程正在執(zhí)行 FLUSH TABLES，并且正在等待所有線程關(guān)閉所訪問(wèn)的表，或者線程得到一個(gè)表的底層結(jié)構(gòu)已經(jīng)改變的通知，它需要重新打開(kāi)表以獲得新的結(jié)構(gòu)。但是，要重新打開(kāi)表，它必須等待，直到所有其他線程都關(guān)閉了舊表結(jié)構(gòu)的訪問(wèn)。如果另一個(gè)線程已在表中使用 FLUSH TABLES 或下列語(yǔ)句之一，則就會(huì)出現(xiàn)這個(gè)通知：

• FLUSH TABLES tbl_name

• ALTER TABLE

• RENAME TABLE

• REPAIR TABLE

• ANALYZE TABLE

• OPTIMIZE TABLE

• Waiting for lock_type lock：server 正在等待獲得一個(gè) THR_LOCK 鎖或者從元數(shù)據(jù)鎖定子系統(tǒng)中獲取一個(gè) MDL 鎖，其中 lock_type 表示正在等待獲得的 MDL 鎖的類型，THR_LOCK 只有一種（Waiting for table level lock），MDL 鎖有如下幾種：

• Waiting for event metadata lock

• Waiting for global read lock

• Waiting for schema metadata lock

• Waiting for stored function metadata lock

• Waiting for stored procedure metadata lock

• Waiting for table metadata lock

• Waiting for trigger metadata lock

• Waiting on cond：線程正在等待條件變?yōu)?true 的通用狀態(tài)。沒(méi)有特定的狀態(tài)信息可用

• Writing to net：server 正在向網(wǎng)絡(luò)寫(xiě)入數(shù)據(jù)包。從 MySQL 5.7.8 之后叫做“Sending to client”

四、dump線程狀態(tài)

• Finished reading one binlog; switching to next binlog：線程已經(jīng)完成讀取 binlog 文
  件，并切換到下一個(gè) binlog 文件

• Master has sent all binlog to slave; waiting for more updates：線程已經(jīng)從二進(jìn)制日志中讀取了所有剩余的更新日志，并將它們發(fā)送到從庫(kù)。線程當(dāng)前處于空閑狀態(tài)，正在等待新的更新數(shù)據(jù)的事件寫(xiě)入二進(jìn)制日志中

• Sending binlog event to slave：線程已經(jīng)從二進(jìn)制日志中讀取了一個(gè)事件，現(xiàn)在將其發(fā)送到從庫(kù)（二進(jìn)制日志由事件組成，一個(gè)事件通常是由發(fā)生更新的數(shù)據(jù)和一些其他信息組成）

• Waiting to finalize termination：線程停止時(shí)發(fā)生的非常短暫的狀態(tài)，線程正在執(zhí)行停止線程相關(guān)的動(dòng)作

五、IO線程狀態(tài)

• Checking master version：在建立與主庫(kù)的連接之后非常短暫的狀態(tài)，表示正在檢查主庫(kù)的版本號(hào)

• Connecting to master：線程嘗試連接到主庫(kù)

• Queueing master event to the relay log：線程已讀取一個(gè)事件，并將其復(fù)制到中繼日志，以便 SQL 線程進(jìn)行重放

• Reconnecting after a failed binlog dump request：線程正在嘗試重新連接到主庫(kù)

• Reconnecting after a failed master event read：線程正在嘗試重新連接到主庫(kù)，當(dāng)重連連接成功時(shí)，狀態(tài)將變?yōu)椤癢aiting for master to send event” - Registering slave on master：在連接到主庫(kù)成功之后非常短暫的狀態(tài)，表示正在向主庫(kù)注冊(cè)從庫(kù)的連接信息（如從庫(kù)的 IP 和端口信息等）

• Requesting binlog dump：在與主庫(kù)建立連接成功之后非常短暫的狀態(tài)，使用當(dāng)
  前的 I/O 線程位置，向主庫(kù)發(fā)送從當(dāng)前位置開(kāi)始的二進(jìn)制日志的內(nèi)容的請(qǐng)求

• Waiting for its turn to commit：如果啟用了 slave_preserve_commit_order 參數(shù)，則
  表示從庫(kù) I/O 線程正在等待較舊的工作線程提交數(shù)據(jù)

• Waiting for master to send event：線程已經(jīng)連接到主庫(kù)并且正在等待新的二進(jìn)制
  日志事件，如果主庫(kù)空閑，這可能持續(xù)很長(zhǎng)時(shí)間。如果等待時(shí)間持續(xù)超過(guò)slave_net_timeout 秒，則從庫(kù) I/O 線程發(fā)生超時(shí)。此時(shí)，從庫(kù) I/O 線程認(rèn)為主庫(kù)的連接斷開(kāi)，會(huì)嘗試重新連接主庫(kù)

• Waiting for master update：連接到主庫(kù)之前的初始狀態(tài)

• Waiting for slave mutex on exit：線程停止時(shí)短暫發(fā)生的狀態(tài)，表示正在回收 I/O 線程的相關(guān)互斥資源

• Waiting for the slave SQL thread to free enough relay log space：如果 relay_log_space_limit 變量設(shè)置值不為 0，那么當(dāng)中繼日志總大小增長(zhǎng)到超過(guò)此值時(shí)。 I/O 線程會(huì)等待，直到 SQL 線程通過(guò)重放中繼日志內(nèi)容并刪除重放完成的中繼日志以釋放中繼日志占用的空間，使其滿足中繼日志中大小不大于 relay_log_space_limit 變量的值時(shí)，I/O 線程才可以繼續(xù)寫(xiě)入中繼日志操作。

• Waiting to reconnect after a failed binlog dump request：如果二進(jìn)制日志 dump 請(qǐng)求失?。ㄓ捎跀嚅_(kāi)連接），那么線程在進(jìn)入 sleep 狀態(tài)，此時(shí)出現(xiàn)此狀態(tài)，然后I/O 線程定期嘗試重新連接主庫(kù)。重試之間的間隔時(shí)間可以使用 CHANGE MASTER TO 語(yǔ)句的 MASTER_CONNECT_RETRY 選項(xiàng)指定

• 要注意，從庫(kù)的 I/O 線程連接主庫(kù)是有心跳機(jī)制的，當(dāng)主庫(kù)超過(guò)這個(gè)心跳時(shí)間沒(méi)有發(fā)送新的 event 到 slave 上時(shí)，I/O 線程就對(duì)主庫(kù)發(fā)起一個(gè)心跳請(qǐng)求，如果請(qǐng)求成功就重置心跳時(shí)間，當(dāng)主庫(kù)有新的 event 發(fā)送到 slave 時(shí)，這個(gè)心跳時(shí) 間 也 會(huì) 進(jìn) 行 重 置 。 心 跳 時(shí) 間 由 change master 語(yǔ)句的MASTER_HEARTBEAT_PERIOD 選項(xiàng)設(shè)置（以秒為單位），范圍 0 到 4294967 秒，分辨率（毫秒）最小非零值為0.001，表示 1 毫秒。將間隔設(shè)置為 0 時(shí)表示禁用心跳。默認(rèn)值是slave_net_timeout 配置參數(shù)的二分之一。so，理論上是不會(huì)出現(xiàn)主從數(shù)據(jù)庫(kù)正常的情況下因?yàn)橹鲙?kù)沒(méi)有寫(xiě)數(shù)據(jù)而導(dǎo)致從庫(kù) I/O 線程斷開(kāi)的情況。

• Waiting to reconnect after a failed master event read：讀取主庫(kù) binlog 時(shí)發(fā)生錯(cuò)誤（由于斷開(kāi)連接）。I/O 線程在嘗試重新連接主庫(kù)之前，線程正在以 CHANGE MASTER TO 語(yǔ)句的 MASTER_CONNECT_RETRY 選項(xiàng)（默認(rèn)為 60）設(shè)置的秒數(shù)進(jìn)行 sleep（該時(shí)間是重連失敗之后的重試間隔時(shí)間）

六、SQL 線程狀態(tài)

• Killing slave：線程正在處理 STOP SLAVE 語(yǔ)句

• Making temporary file（append）before replaying LOAD DATA INFILE：線程正在執(zhí)行 LOAD DATA INFILE 語(yǔ)句，并將從庫(kù)將要讀取的數(shù)據(jù)添加到臨時(shí)文件中

• Making temporary file（create）before replaying LOAD DATA INFILE：線程正在執(zhí)行 LOAD DATA INFILE 語(yǔ)句，且正在創(chuàng)建臨時(shí)文件，臨時(shí)文件中包含了從庫(kù)將要讀取行數(shù)據(jù)。注意：只有在 MySQL 5.0.3 之前的版本中，主庫(kù)記錄了原始LOAD DATA INFILE 語(yǔ)句時(shí)，才能遇到此狀態(tài)

• Reading event from the relay log：線程正在從中繼日志中讀取事件，以便進(jìn)行重放

• Slave has read all relay log; waiting for more updates：線程已重做完所有的中繼日志文件中的所有事件，正在等待 I/O 線程向中繼日志中寫(xiě)入新的事件

• Waiting for an event from Coordinator：從庫(kù)使用多線程復(fù)制時(shí)（slave_parallel_workers 大于 1），此狀態(tài)表示一個(gè) slave works 線程正在等待協(xié)調(diào)器線程（Coordinator 線程）分配日志事件

• Waiting for slave mutex on exit：線程停止時(shí)發(fā)生的非常短暫的狀態(tài)

• Waiting for Slave Workers to free pending events：當(dāng) Workers 線程處理的事件的總數(shù)量大小超過(guò) slave_pending_jobs_size_max 系統(tǒng)變量的大小時(shí)，會(huì)發(fā)生等待操作（協(xié)調(diào)器線程不進(jìn)行分配事件給 worker 線程）。當(dāng) Workers 線程處理的事件的總數(shù)量大小低于 slave_pending_jobs_size_max 限制時(shí)，協(xié)調(diào)器恢復(fù)調(diào)度。只有當(dāng) slave_parallel_workers 設(shè)置為大于 0 時(shí)，此狀態(tài)才會(huì)出現(xiàn)

• Waiting for the next event in relay log：“Reading event from the relay log”狀態(tài)之前的初始狀態(tài)

• Waiting until MASTER_DELAY seconds after master executed event：SQL 線程已讀取事件，但并沒(méi)有進(jìn)行應(yīng)用，而是正在等待從庫(kù)設(shè)置的延遲復(fù)制時(shí)間失效。此延遲時(shí)間使用 CHANGE MASTER TO 的 MASTER_DELAY 選項(xiàng)設(shè)置
  ? SQL 線程的 Info 列也可以顯示語(yǔ)句的文本。這表示線程已經(jīng)從中繼日志中讀取了一個(gè)事件，并從中提取了 SQL 語(yǔ)句，當(dāng)前可能正在執(zhí)行這個(gè)語(yǔ)句對(duì)應(yīng)的事件。

七、 主從連接線程狀態(tài)

• Changing master：線程正在處理 CHANGE MASTER TO 語(yǔ)句

• Killing slave：線程正在處理 STOP SLAVE 語(yǔ)句

• Opening master dump table：此狀態(tài)發(fā)生在主庫(kù)創(chuàng)建 dump 表之后

• Reading master dump table data："Opening master dump table"狀態(tài)之后出現(xiàn)的狀態(tài)，表示正在從主庫(kù) dump 表讀取數(shù)據(jù)

• Rebuilding the index on master dump table：“Reading master dump table data”狀態(tài)之后出現(xiàn)的狀態(tài)，表示正在重建主庫(kù) dump 表索引

八、事件調(diào)度線程狀態(tài)

• Clearing：調(diào)度程序線程正在停止執(zhí)行事件

• Initialized：調(diào)度程序線程已初始化完成，將要執(zhí)行調(diào)度事件

• Waiting for next activation：調(diào)度程序具有非空事件隊(duì)列時(shí)，正在等待未來(lái)某個(gè)時(shí)間點(diǎn)激活隊(duì)列中的某個(gè)事件，以便進(jìn)行調(diào)度并執(zhí)行

• Waiting for scheduler to stop：線程發(fā)出 SET GLOBAL event_scheduler = OFF 并等待調(diào)度程序停止

• Waiting on empty queue：調(diào)度程序的事件隊(duì)列為空，因此調(diào)度程序處于休眠狀態(tài)

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“MySQL線程狀態(tài)的示例分析”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持億速云，關(guān)注億速云行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來(lái)學(xué)習(xí)!