本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Aurora MySQL 執行緒狀態
<a name="AuroraMySQL.Reference.thread-states"></a>

以下是 Aurora MySQL 的一些常見執行緒狀態。

**檢查許可**  
執行緒正在檢查伺服器是否具有執行陳述式所需的權限。

**檢查查詢快取中是否有查詢**  
伺服器正在檢查目前的查詢是否存在於查詢快取中。

**已清除**  
這是連線的最終狀態，表示其工作已完成，但用戶端尚未將其關閉。最好的解決方案是明確關閉程式碼中的連線。或者，您可以在參數群組中為 `wait_timeout` 設定較低的值。

**關閉資料表**  
執行緒正在將已變更的資料表資料清空到磁碟並關閉已使用的資料表。如果這不是快速作業，請針對執行個體類別網路頻寬來驗證網路頻寬耗用指標。另外，請檢查 `table_open_cache` 和 `table_definition_cache` 參數的參數值是否允許足夠的資料表同時開啟，以便引擎不需要經常開啟和關閉資料表。這些參數會影響執行個體上的記憶體耗用量。

**將 HEAP 轉換為 MyISAM**  
查詢正在將暫時資料表從記憶體內轉換為磁碟。這種轉換是必要的，因為在查詢處理的中繼步驟中由 MySQL 建立的暫時資料表對於記憶體來說增長太大。檢查 `tmp_table_size` 和 `max_heap_table_size` 的值。在更新的版本中，這個執行緒狀態名稱是 `converting HEAP to ondisk`。

**將 HEAP 轉換為 ondisk**  
執行緒正在將內部暫時資料表從記憶體內資料表轉換為磁碟上資料表。

**複製到 tmp 資料表**  
執行緒正在處理 `ALTER TABLE` 陳述式。在建立了具有新結構的資料表之後，但在將資料列複製到其中之前，會發生此狀態。對於處於此狀態的執行緒，您可以使用效能結構描述來取得複製作業進度的相關資訊。

**建立排序索引**  
Aurora MySQL 正在執行排序，因為它不能使用現有的索引來滿足查詢的 `ORDER BY` 或 `GROUP BY`子句。如需更多詳細資訊，請參閱 [正在建立排序索引](ams-states.sort-index.md)。

**建立資料表**  
執行緒正在建立永久或暫時資料表。

**延遲遞交已順利完成**  
Aurora MySQL 中的非同步遞交已收到確認，且已完成。

**延遲遞交已順利啟動**  
Aurora MySQL 執行緒已啟動非同步遞交程序，但正在等待確認。這通常是交易的真正遞交時間。

**延遲傳送已順利完成**  
當回應傳送至用戶端時，可以釋放繫結至連線的 Aurora MySQL 工作者執行緒。執行緒可以開始其他工作。狀態 `delayed send ok` 表示對用戶端的非同步確認已完成。

**延遲傳送已順利啟動**  
Aurora MySQL 工作者執行緒已非同步地將回應傳送至用戶端，現在可以自由地為其他連線執行工作。交易已啟動尚未確認的非同步遞交程序。

**執行中**  
執行緒已開始執行陳述式。

**釋放項目**  
執行緒已執行命令。某些在此狀態期間完成的項目釋放涉及查詢快取。這種狀態通常伴隨著清除。

**init**  
這種狀態在初始化 `ALTER TABLE`、`DELETE`、`INSERT`、`SELECT` 或 `UPDATE` 陳述式之前發生。處於此狀態的動作包括清空二進位日誌或 InnoDB 日誌，以及查詢快取的部分清除。

**來源已將所有 binlog 傳送至複本；正在等待更多更新**  
主節點已完成其複寫部分。執行緒正在等待更多的查詢執行，以便它可以寫入至二進位日誌 (Binlog)。

**開啟表格**  
執行緒正在嘗試開啟資料表。此作業速度很快，除非 `ALTER TABLE` 或 `LOCK TABLE` 陳述式需要完成，否則它會超過 `table_open_cache` 的值。

**最佳化 **  
伺服器正在執行查詢的初始最佳化。

**準備中**  
此狀態發生在查詢最佳化期間。

**查詢結束**  
在處理查詢之後，但在釋放項目狀態之前，會發生此狀態。

**移除重複項目**  
Aurora MySQL 無法在查詢的早期階段最佳化 `DISTINCT` 作業。Aurora MySQL 必須在將結果傳送至用戶端之前移除所有重複的資料列。

**搜尋資料列以進行更新**  
執行緒正在尋找所有相符的資料列，然後再更新它們。如果 `UPDATE` 正在變更引擎用來尋找資料列的索引，這個階段是必要的。

**將 Binlog 事件傳送到從屬節點**  
執行緒已從二進位日誌讀取事件，並正在將其傳送到複本。

**將快取的結果傳送到用戶端**  
伺服器正在從查詢快取中取得查詢的結果，並將其傳送到用戶端。

**傳送資料**  
執行緒正在讀取和處理 `SELECT` 陳述式的資料列，但尚未開始將資料傳送至用戶端。此程序正在識別哪些頁面包含滿足查詢所需的結果。如需更多詳細資訊，請參閱 [正在傳送資料](ams-states.sending-data.md)。

**傳送至用戶端**  
伺服器正在將封包寫入至用戶端。在早期的 MySQL 版本中，此等待事件被標記為 `writing to net`。

**開始**  
這是在陳述式執行開始的第一個階段。

**統計資訊**  
伺服器正在計算統計資料以開發查詢執行計劃。如果執行緒長時間處於這種狀態，伺服器可能在執行其他工作時受到磁碟限制。

**將結果存放在查詢快取中**  
伺服器正在將查詢的結果存放在查詢快取中。

**系統鎖定**  
執行緒已呼叫 `mysql_lock_tables`，但執行緒狀態自呼叫以來未更新過。發生這種一般狀態的原因很多。

**update**  
執行緒正在準備開始更新資料表。

**更新**  
執行緒正在搜尋資料列並更新它們。

**使用者鎖定**  
執行緒已發出 `GET_LOCK` 呼叫。執行緒已請求一個建議鎖定並正在等待它，或者正在規劃請求它。

**等待更多更新**  
主節點已完成其複寫部分。執行緒正在等待更多的查詢執行，以便它可以寫入至二進位日誌 (Binlog)。

**等待結構描述中繼資料鎖定**  
這表示等待中繼資料鎖定。

**等待預存函數中繼資料鎖定**  
這表示等待中繼資料鎖定。

**等待預存程序中繼資料鎖定**  
這表示等待中繼資料鎖定。

**等待資料表清空**  
執行緒正在執行 `FLUSH TABLES` 並等待所有執行緒關閉其資料表。或者，執行緒收到了資料表的基礎結構已變更的通知，因此它必須重新開啟資料表以取得新結構。若要重新開啟資料表，執行緒必須等到所有其他執行緒關閉了資料表。如果另一個執行緒已在資料表上使用下列其中一個陳述式，就會發生此通知：`FLUSH TABLES`、`ALTER TABLE`、`RENAME TABLE`、`REPAIR TABLE`、`ANALYZE TABLE` 或 `OPTIMIZE TABLE`。

**等待資料表層級鎖定**  
一個工作階段對資料表保有鎖定，而另一個工作階段嘗試對同一資料表取得相同的鎖定。

**等待執行緒中繼資料鎖定**  
Aurora MySQL 使用中繼資料鎖定來管理資料庫物件的並行存取，並確保資料一致性。在此等待事件中，一個工作階段對資料表保有中繼資料鎖定，而另一個工作階段嘗試對同一資料表取得相同的鎖定。啟用效能結構描述時，此執行緒狀態會報告為等待事件 `synch/cond/sql/MDL_context::COND_wait_status`。

**寫入至網路**  
伺服器正在將封包寫入至網路。在更新的 MySQL 版本中，此等待事件被標記為 `Sending to client`。