- 線程的 Command 值
| Binlog Dump | 這是主庫上的一個線程，用於將二進制日誌內容發送到 從庫 |
| Change user | 線程正在執行更改用戶操作 |
| Close stmt | 線程正在關閉一個預編譯好的語句 |
| Connect | 從庫線程已經連接到主庫 |
| Connect Out | 從庫正在連接到主庫 |
| Create DB | 線程正在執行一個建庫操作 |
| Daemon | 這個是 server 內部線程，不是客戶端連接的線程 |
| Debug | 線程正在生成調試信息 |
| Delayed insert | 是一個延遲插入處理程序的線程 |
| Drop DB | 線程正在執行 drop database 操作 |
| Error | |
| Execute | 線程正在執行一個預編譯好的語句 |
| Fetch | 線程正在執行語句並從中獲取結果集 |
| Field List | 線程正在檢索表列的信息 |
| Init DB | 線程正在選擇默認數據庫 |
| kill | 線程正在殺死其他線程 |
| Long Data | 線程在執行語句並從中檢索並返回長字段（大字段）類型 的數據結果集 |
| Ping | 線程正在處理服務器 ping 請求 |
| Prepare | 線程正在執行預編譯一個語句 |
| Processlist | 線程正在生成有關 server 線程的信息 |
| Query | 線程正在執行查詢語句 |
| Quit | 線程正在終止 |
| Refresh | 線程正在刷新表，日誌或高速緩存，或重置狀態變量或複製 server 信息 |
| Register Slave | 線程正在主庫上註冊從庫 |
| Reset stmt | 線程正在重置預編譯語句 |
| Set option | 線程正在設置或重置客戶端語句執行選項 |
| Shutdown | 線程正在執行關閉 server |
| Sleep | 線程正在等待客戶端向其發送一個新語句請求 |
| Statistics | 線程正在生成 server 狀態信息 |
| Table Dump | 線程正在將表內容發送到從庫 |
| Time | 當前未使用 |
- 普通線程狀態 非內部機制創建的線程
| After create | 當線程創建一個表完成時，包括內部臨時表,會出現這種狀態，如果建表失敗也會出現 |
| Analyzing | 線程正在計算 MyISAM 表的 key 分佈 ANALYZE TABLE |
| checking permissions | 正在 server 中檢查線程是否具有執行 語句所需的權限 |
| Checking table | 線程正在執行表檢查操作 |
| cleaning up | 線程已經執行完成了一個命令，並準備釋放所佔用 的內存和重置某些狀態變量 |
| closing tables | 線程正在將表發生更改的數據刷新到磁盤並關閉 表。通常情況下這個操作很快。否則，請檢查磁盤空間是否滿 了，或者磁盤的負載是否比較高 |
| converting HEAP to MyISAM | 線程正在將內部臨時表從 MEMORY 引擎錶轉換爲磁盤 MyISAM 引擎的臨時表 |
| copy to tmp table | ：線程正在執行 ALTER TABLE 語句。此狀態 發生在新結構的表已經創建好之後，執行 copy 舊錶數據到新表 中之前出現，這裏對於線程的具體執行詳情，可以使用 performance_schema 庫來獲取有關 copy 操作的進度信息 |
| Copying to group table | 如果語句使用了不同的 ORDER BY 和 GROUP BY 條件列，則按照 group by 對這些行數據進行排 序，並將排序結果複製到臨時表 |
| Copying to tmp table | server 正在複製數據到內存臨時表 |
| altering table | server 正在執行 in-place 算法的 ALTER TABLE 的過程 |
| Copying to tmp table on disk | server 正在複製數據到磁盤臨 時表。因爲臨時結果集太大，所以，線程正在將內存臨時錶轉換 爲基於磁盤的臨時表，以節省內存 |
| Creating index | 線程正在執行一個 MyISAM 表的 ALTER TABLE ... ENABLE KEYS 語句 |
| Creating sort index | 線程正在執行 SELECT 且使用到了內部臨 時表 |
| creating table | 線程正在創建表。包括創建臨時表時也會使用 此狀態 |
| Creating tmp table | 線程正在內存或磁盤上創建一個臨時表。 如果表在內存中創建，但後來被轉換爲磁盤表，則該操作期間的 狀態將爲“Copying to tmp table on disk” |
| committing alter table to storage engine | server 已執行完 成 in-place 算法的 ALTER TABLE 語句，正在提交 |
| deleting from main table | server 正在執行多表刪除語句中的 第一部分。看到這個狀態表示正在從第一個表中刪除，並保存後 續用於刪除其他表的列數據和偏移量 |
| deleting from reference tables | server 正在執行多表刪除語 句的第二部分，從其他表（非第一個表）中刪除匹配的行 |
| discard_or_import_tablespace | 線程正在執行 ALTER TABLE ... DISCARD TABLESPACE 或 ALTER TABLE ... IMPORT TABLESPACE 語句 |
| end | 這發生在語句執行結束時，但在清除 ALTER TABLE， CREATE VIEW，DELETE，INSERT，SELECT 或 UPDATE 語句 之前出現該狀態 |
| executing | 線程正在執行語句中 |
| Execution of init_command | 線程正在執行一個初始化系統變 量的語句 |
| freeing items | 線程已經執行完成了一個命令。釋放一些涉及到 query cache 狀態的 items。這種狀態後通常緊隨 cleaning up 狀態之後 |
| FULLTEXT initialization | server 正在準備執行自然語言全文搜 索 |
| init | ：這在 ALTER TABLE，DELETE，INSERT，SELECT 或 UPDATE 語句初始化之前發生的狀態。server 在此狀態下執行的 操作包括刷新二進制日誌，InnoDB 日誌和一些查詢緩存清理操 作。對於這個狀態結束時，可能會有如下一些操作： * 當表中的數據更改後刪除查詢緩存條目 * 將事件寫入二進制日誌 * 釋放內存緩衝區，包括 blob |
| Killed | 向線程發起一個 kill 操作，線程應該執行終止操作。在 MySQL 的每個主循環中檢查線程的 kill 標誌，但在某些情況下， 殺死線程可能只需要很短的時間。但如果被 kill 的線程被其他線 程鎖定，則需要等待其他線程釋放鎖之後，kill 命令纔會生效並 執行 |
| logging slow query | 線程正在向慢查詢日誌寫一條語句 |
| login | 連接線程的初始狀態，直到客戶端成功通過身份驗證 |
| manage keys | server 正在啓用或禁用表索引 |
| NULL | 此狀態用於 SHOW PROCESSLIST 語句 |
| Opening tables | 線程正嘗試打開一個表。打開表操作應該非常 快，除非打開操作被阻止。例如，ALTER TABLE 或 LOCK TABLE 語句可以防止打開表，直到該語句完成。另外也可能是 table_open_cache 不夠大導致不能打開表 |
| optimizing | server 正在對查詢執行初始優化 |
| preparing | 此狀態發生在查詢優化期間 |
| Purging old relay logs | 線程正在刪除不需要的中繼日誌文件 o query end：此狀態出現在執行查詢語句之後但在釋放該查詢語 句相關狀態 items 之前 |
| Reading from net | server 正在從網絡讀取數據包。在 MySQL 5.7.8 之後該狀態叫做“Receiving from client ” |
| Receiving from client | server 正在從客戶端讀取數據包。在 MySQL 5.7.8 叫做“Reading from net ” |
| Removing duplicates | 查詢使用 SELECT DISTINCT 語句時， 使 MySQL 無法在早期階段優化掉 distinct 操作。因此，MySQL 需要一個額外的階段來刪除所有重複的行，然後將結果發送到客 戶端 |
| removing tmp table | 線程在 SELECT 語句執行完成後，正在刪 除內部臨時表。如果 SELECT 語句未創建臨時表，則不會出現此 狀態 |
| rename | 線程正在執行 rename 語句重命名錶 |
| rename result table | 線程正在執行 ALTER TABLE 語句重命名 表，已經創建完成新表，並正在使用新表替換舊錶名稱 |
| Reopen tables | 線程獲得了表鎖，但是獲得鎖後，發現基礎表 結構已經被改變了。於是釋放表鎖，並關閉表，嘗試重新打開表 |
| Repair by sorting | 修復代碼正在使用排序來創建索引 |
| preparing for alter table | server 正在準備執行 in-place 算法 的 ALTER TABLE 語句 |
| Repair done | 該線程已完成 MyISAM 表的多線程修復 |
| Repair with keycache | 修復代碼正在使用通過 key cache 逐個 創建 key 的方法修復索引。這比通過排序索引修復的方法慢得多 |
| Rolling back | 線程正在回滾事務 |
| Saving state | 對於 MyISAM 表操作（如修復或分析），線程正 在將新表狀態保存到.MYI 文件頭。狀態包括：表數據行數， AUTO_INCREMENT 計數器和 key 分佈之類的信息 |
| Searching rows for update | 線程正在進行第一階段查找所有 匹配的行，然後再更新它們。如果 UPDATE 正在更改用於查找涉 及的行的索引，則必須先把 update 滿足匹配的行先查找出來 |
| Sending data | 線程正在讀取和處理 SELECT 語句產生的數據 行，並將數據發送到客戶端。因爲在此狀態期間發生的操作可能 產生大量的磁盤訪問（讀取），所以它通常是給定查詢的生存期 內最長的運行狀態 |
| Sending to client | server 正在向客戶端寫入數據包。在 MySQL 5.7.8 之前叫做“Writing to net” |
| setup | 線程正在執行 ALTER TABLE 操作 |
| Sorting for group | 線程正在執行一個 GROUP BY 排序操作 |
| Sorting for order | 線程正在執行一個 ORDER BY 排序操作 |
| Sorting index | 線程正在排序索引頁面，以便在 MyISAM 表優 化操作期間實現更高效的訪問 |
| Sorting result | 對於 SELECT 語句，這類似於“Creating sort index”狀態，但是針對於非臨時表 |
| statistics | server 正在計算統計信息以優化查詢執行計劃。如果 一個線程在這個狀態很長一段時間，server 可能是磁盤執行其他 工作而阻塞了統計信息的操作，也有可能發生了鎖等待。 |
| System lock | 線程調用了 mysql_lock_tables()，線程狀態從未 更新過。這是一個非常常見的狀態，出現該狀態的原因有很多。 例如，線程將請求或正在等待表的內部或外部系統鎖定。當 InnoDB 在執行 LOCK TABLES 期間等待表級鎖時，可能會發生 這種情況。如果此狀態是由外部鎖請求引起的，如果您不使用多 個 mysqld 服務器訪問同一 MyISAM 表，則可以使用--skipexternal-locking 選項禁用外部系統鎖。但是，默認情況下外部 鎖定是禁用的，因此此選項可能無效。對於 SHOW PROFILE， 此狀態表示線程正在請求鎖定（不等待） |
| update | 線程準備開始更新表 |
| Updating | 線程搜索且正在更新數據行 |
| updating main table | server 正在執行多表更新語句的第一部 分。該狀態表示正在更新第一個表，並保存列值和偏移量以用於 更新其他（引用）表 |
| updating reference tables | server 正在執行多表更新語句的第 二部分，更新其他表的匹配行 |
| User lock | 線程將請求或正在等待通過 GET_LOCK() 調用請求 的建議鎖。對於 SHOW PROFILE，此狀態表示線程正在請求鎖 定（無需等待） |
| User sleep | 線程已調用 SLEEP() 調用 |
| Waiting for commit lock | FLUSH TABLES WITH READ LOCK 語句正在獲取提交鎖 |
| Waiting for global read lock | FLUSH TABLES WITH READ LOCK 正在等待獲取全局讀鎖或全局 read_only 系統變量設置 |
| Waiting for tables | 線程獲取到一個通知，表的底層結構已經改 變，它需要重新打開表以獲得新的結構。但是，要重新打開表， 它必須等待，直到所有其他線程都關閉了舊數據結構的表的訪 問。如果另一個線程已在表中使用 FLUSH TABLES 或下列語句之 一，則就會出現這個通知： * FLUSH TABLES tbl_name * ALTER TABLE * RENAME TABLE * REPAIR TABLE * ANALYZE TABLE * OPTIMIZE TABLE |
| Waiting for table flush | 線程正在執行 FLUSH TABLES，並且 正在等待所有線程關閉所訪問的表，或者線程得到一個表的底層 結構已經改變的通知，它需要重新打開表以獲得新的結構。但 是，要重新打開表，它必須等待，直到所有其他線程都關閉了舊 表結構的訪問。如果另一個線程已在表中使用 FLUSH TABLES 或 下列語句之一，則就會出現這個通知： * FLUSH TABLES tbl_name * ALTER TABLE * RENAME TABLE * REPAIR TABLE * ANALYZE TABLE * OPTIMIZE TABLE |
| Waiting for lock_type lock | server 正在等待獲得一個 THR_LOCK 鎖或者從元數據鎖定子系統中獲取一個 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 | 線程正在等待條件變爲 true 的通用狀態。沒 有特定的狀態信息可用 |
| Writing to net | server 正在向網絡寫入數據包。從 MySQL 5.7.8 之後叫做“Sending to client” |