本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # synch/cond/sql/MDL\_context::COND\_wait\_status 有執行緒正在等待資料表中繼資料鎖定時，`synch/cond/sql/MDL_context::COND_wait_status` 事件便會發生。 **Topics** + [支援的引擎版本](#ams-waits.cond-wait-status.context.supported) + [Context](#ams-waits.cond-wait-status.context) + [等待變多的可能原因](#ams-waits.cond-wait-status.causes) + [動作](#ams-waits.cond-wait-status.actions) ## 支援的引擎版本 下列引擎版本支援這個等待事件資訊： + Aurora MySQL 2 版和 3 版 ## Context 事件 `synch/cond/sql/MDL_context::COND_wait_status` 指出有執行緒正在等待資料表中繼資料鎖定。在某些情況下，一個工作階段對資料表保有中繼資料鎖定，而另一個工作階段嘗試對同一資料表取得相同的鎖定。在這類情況下，第二個工作階段會等待 `synch/cond/sql/MDL_context::COND_wait_status` 等待事件。 MySQL 使用中繼資料鎖定來管理資料庫物件的並行存取，並確保資料一致性。中繼資料鎖定適用於資料表、結構描述、排程事件、資料表空間，以及使用 `get_lock` 函數和預存程式取得的使用者鎖定。預存程式包含程序、函數和觸發程序。如需詳細資訊，請參閱 MySQL 文件中的[中繼資料鎖定](https://dev.mysql.com/doc/refman/5.7/en/metadata-locking.html)。 MySQL 程序清單顯示這個工作階段處於狀態 `waiting for metadata lock` 中。在績效詳情中，如果 `Performance_schema` 已開啟，事件 `synch/cond/sql/MDL_context::COND_wait_status` 即會出現。 等待中繼資料鎖定之查詢的預設逾時是基於 `lock_wait_timeout` 參數的值，預設值為 31,536,000 秒 (365 天)。 如需有關不同 InnoDB 鎖定和可能導致衝突之鎖定類型的詳細資訊，請參閱 MySQL 文件中的 [InnoDB 鎖定](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html)。 ## 等待變多的可能原因 `synch/cond/sql/MDL_context::COND_wait_status` 事件比平時更常出現時，可能表示有效能問題，典型原因包括： **長時間執行的交易** 一個或多個交易正在修改大量的資料，並對資料表保留鎖定很長一段時間。 **交易閒置** 一個或多個交易保持開啟狀態很長一段時間，沒有進行遞交或復原。 **大型表格上的 DDL 陳述式** 一或多個資料定義語言 (DDL) 陳述式，例如 `ALTER TABLE` 命令，已在非常大的資料表上執行。 **明確資料表鎖定** 未及時釋放的資料表上有明確的鎖定。例如，應用程式可能會不當地執行 `LOCK TABLE` 陳述式。 ## 動作 我們會建議不同的動作，取決於等待事件的原因，以及 Aurora MySQL 資料庫叢集的版本。 **Topics** + [識別造成事件的工作階段和查詢](#ams-waits.cond-wait-status.actions.identify) + [檢查是否有過去的活動](#ams-waits.cond-wait-status.actions.past-events) + [在 Aurora MySQL 第 2 版上執行查詢](#ams-waits.cond-wait-status.actions.run-queries-aurora-mysql-57) + [回應封鎖工作階段](#ams-waits.cond-wait-status.actions.blocker) ### 識別造成事件的工作階段和查詢 您可以使用績效詳情來顯示 `synch/cond/sql/MDL_context::COND_wait_status` 等待事件所封鎖的查詢。不過，若要識別封鎖工作階段，請從資料庫叢集上的 `performance_schema` 和 `information_schema` 查詢中繼資料表。 通常，具有中等至重大負載的資料庫會有等待事件。如果效能是最佳的，則等待事件可能是可以接受的。如果效能不是最佳的，則檢查資料庫在何處花費最多時間。查看造成最高負載的等待事件，並了解您是否可以最佳化資料庫和應用程式，以減少這些事件。 **尋找負責高負載的 SQL 查詢** 1. 登入 AWS 管理主控台 並開啟位於 https：//[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) 的 Amazon RDS 主控台。 1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。 1. 選擇資料庫執行個體。該資料庫執行個體的績效詳情儀表板即會出現。 1. 在 **Database load** (資料庫負載) 圖表中，選擇 **Slice by wait** (依等待建立配量)。 1. 在頁面底端，選擇 **Top SQL** (最高 SQL)。 此圖表會列出負責負載的 SQL 查詢。位於清單頂端者負最大責任。若要解決瓶頸，請專注於這些陳述式。 如需使用績效詳情進行故障診斷的實用概觀，請參閱 AWS 資料庫部落格文章[使用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。 ### 檢查是否有過去的活動 您可以洞察這個等待事件，以檢查其是否發生過。若要這樣做，請完成下列動作。 + 檢查資料處理語言 (DML) 和 DDL 輸送量和延遲，以查看工作負載是否有任何變更。 您可以使用績效詳情來尋找問題發生時等待此事件的查詢。此外，您也可以檢視接近問題發生時的查詢執行摘要。 + 如果開啟資料庫叢集的稽核日誌或一般日誌，您可以檢查所有查詢是否在等待交易中涉及的物件 (schema.table) 上執行。您也可以檢查是否有查詢在交易之前已完成執行。 疑難排解過去事件的可用資訊有限。執行這些檢查不會顯示哪個物件正在等待資訊。不過，您可以識別事件發生時負載繁重的資料表，以及發生問題時導致衝突的常操作資料列集。然後，您可以使用此資訊，在測試環境中重現問題，並提供有關其原因的洞察。 ### 在 Aurora MySQL 第 2 版上執行查詢 在 Aurora MySQL 第 2 版中，您可以查詢 `performance_schema` 資料表或 `sys` 結構描述檢視，直接識別已封鎖的工作階段。範例可說明如何查詢資料表，以識別封鎖查詢和工作階段。 在下列程序清單輸出中，連線ID `89` 正在等待中繼資料鎖定，並且正在執行 `TRUNCATE TABLE` 命令。在查詢中，於 `performance_schema` 資料表或 `sys` 結構描述檢視上，輸出會顯示封鎖工作階段是 `76`。 ``` MySQL [(none)]> select @@version, @@aurora_version; +-----------+------------------+ | @@version | @@aurora_version | +-----------+------------------+ | 5.7.12 | 2.11.5 | +-----------+------------------+ 1 row in set (0.01 sec) MySQL [(none)]> show processlist; +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ | 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL | | 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL | | 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL | | 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL | | 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL | | 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL | | 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL | | 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL | | 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL | | 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL | | 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL | | 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL | | 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL | | 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL | | 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL | | 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist | | 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) | | 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 | +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ 18 rows in set (0.00 sec) ``` 接下來，`performance_schema` 資料表或 `sys` 結構描述檢視上的查詢會顯示封鎖工作階段是 `76`。 ``` MySQL [(none)]> select * from sys.schema_table_lock_waits; +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ | object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection | +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ | sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 | +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ 1 row in set (0.00 sec) ``` ### 回應封鎖工作階段 當您識別工作階段時，您的選項包括下列項目： + 聯絡應用程式擁有者或使用者。 + 如果封鎖工作階段閒置，請考慮結束封鎖工作階段。此動作可能會觸發長時間回復。若要了解如何結束工作階段，請參閱 [結束工作階段或查詢](mysql-stored-proc-ending.md)。 如需識別封鎖交易的詳細資訊，請參閱 MySQL 文件中的[使用 InnoDB 交易與鎖定資訊](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html)。