# synch/cond/sql/MDL\$1context::COND\$1wait\$1status 当有正等待表元数据锁定的线程时，会发生 `synch/cond/sql/MDL_context::COND_wait_status` 事件。 **Topics** + [支持的引擎版本](#ams-waits.cond-wait-status.context.supported) + [上下文](#ams-waits.cond-wait-status.context) + [等待次数增加的可能原因](#ams-waits.cond-wait-status.causes) + [操作](#ams-waits.cond-wait-status.actions) ## 支持的引擎版本 以下引擎版本支持此等待事件信息： + Aurora MySQL 版本 2 和 3 ## 上下文 事件 `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` 参数的值，该值原定设置为 31536000 秒（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 管理控制台 并通过以下网址打开 Amazon RDS 控制台：[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)。 1. 在导航窗格中，选择**性能详情**。 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)。