Aurora MySQL 等待事件 - Amazon Aurora

Aurora MySQL 等待事件

以下是 Aurora MySQL 的一些常见等待事件。

注意

有关使用等待事件调整 Aurora MySQL 性能的信息,请参阅使用等待事件优化 Aurora MySQL

有关 MySQL 等待事件中使用的命名约定的信息,请参阅 MySQL 文档中的性能架构测试命名约定

cpu

准备运行的活动连接数一直高于 vCPU 的数量。有关更多信息,请参阅cpu

io/aurora_redo_log_flush

会话将数据持久存储到 Aurora 存储。通常,该等待事件针对 Aurora MySQL 中的写入 I/O 操作。有关更多信息,请参阅io/aurora_redo_log_flush

io/aurora_respond_to_client

以下 Aurora MySQL 版本的查询处理已完成,结果将返回到应用程序客户端:2.10.2 及更高的 2.10 版本、2.09.3 及更高的 2.09 版本和 2.07.7 及更高的 2.07 版本。将数据库实例类的网络带宽与返回的结果集的大小进行比较。另外,请检查客户端响应时间。如果客户端无响应且无法处理 TCP 数据包,则可能会发生数据包丢弃和 TCP 重新传输。这种情况会对网络带宽产生负面影响。在低于 2.10.2、2.09.3 和 2.07.7 的版本中,等待事件错误地包含空闲时间。要了解如何在此等待突出时优化数据库,请参阅 io/aurora_respond_to_client

io/file/csv/data

线程以逗号分隔值 (CSV) 格式写入表。检查您的 CSV 表使用情况。此事件的典型原因是在表上设置 log_output

io/file/sql/binlog

线程在等待正写入磁盘的二进制日志 (binlog) 文件。

io/redo_log_flush

会话将数据持久存储到 Aurora 存储。通常,该等待事件针对 Aurora MySQL 中的写入 I/O 操作。有关更多信息,请参阅io/redo_log_flush

io/socket/sql/client_connection

mysqld 程序正忙于创建线程来处理传入的新客户端连接。有关更多信息,请参阅io/socket/sql/client_connection

io/table/sql/handler

引擎正在等待访问表格。无论数据是缓存在缓冲池中还是可在磁盘上访问,都会发生此事件。有关更多信息,请参阅io/table/sql/handler

lock/table/sql/handler

该等待事件是表锁定等待事件处理程序。有关性能架构中的“原子”和“分子”事件的更多信息,请参阅 MySQL 文档中的性能架构原子和分子事件

synch/cond/innodb/row_lock_wait

多个数据操作语言 (DML) 语句同时访问相同的数据库行。有关更多信息,请参阅synch/cond/innodb/row_lock_wait

synch/cond/innodb/row_lock_wait_cond

多条 DML 语句同时访问相同的数据库行。有关更多信息,请参阅synch/cond/innodb/row_lock_wait_cond

synch/cond/sql/MDL_context::COND_wait_status

线程正等待表元数据锁定。引擎使用这种类型的锁定来管理对数据库架构的并发访问并确保数据的一致性。有关更多信息,请参阅 MySQL 文档中的优化锁定操作。要了解如何在此事件突出时优化数据库,请参阅 synch/cond/sql/MDL_context::COND_wait_status

synch/cond/sql/MYSQL_BIN_LOG::COND_done

您已开启二进制日志记录。可能存在较高的提交吞吐量、大量事务提交或读取二进制日志的副本。考虑使用多行语句或将语句捆绑到一个事务中。在 Aurora 中,使用全局数据库而不是二进制日志复制,或者使用 aurora_binlog_* 参数。

synch/mutex/innodb/aurora_lock_thread_slot_futex

多条 DML 语句同时访问相同的数据库行。有关更多信息,请参阅synch/mutex/innodb/aurora_lock_thread_slot_futex

synch/mutex/innodb/buf_pool_mutex

缓冲池不够大,无法容纳正常工作的数据集。或者,工作负载访问特定表中的页面,这会导致缓冲池中的争用。有关更多信息,请参阅synch/mutex/innodb/buf_pool_mutex

synch/mutex/innodb/fil_system_mutex

该进程正在等待对表空间内存缓存的访问。有关更多信息,请参阅synch/mutex/innodb/fil_system_mutex

synch/mutex/innodb/trx_sys_mutex

操作正在以一致或受控的方式在 InnoDB 中检查、更新、删除或添加事务 ID。这些操作需要 trx_sys 互斥调用,该调用由性能架构工具跟踪。操作包括在数据库启动或关闭时管理事务系统、回滚、撤消清理、行读取访问和缓冲池加载。高数据库负载和大量事务导致此等待事件频繁出现。有关更多信息,请参阅synch/mutex/innodb/trx_sys_mutex

synch/mutex/mysys/KEY_CACHE::cache_lock

keycache->cache_lock 互斥控制对 MyISAM 表的密钥缓存的访问。虽然 Aurora MySQL 不允许使用 MyISAM 表来存储持久数据,但它们用于存储内部临时表。考虑检查 created_tmp_tablescreated_tmp_disk_tables 状态计数器,因为在某些情况下,当临时表不再适合放入内存中时,会将其写入磁盘。

synch/mutex/sql/FILE_AS_TABLE::LOCK_offsets

在打开或创建表元数据文件时,引擎会获取此互斥。当此等待事件发生频率过高时,创建或打开的表的数量会激增。

synch/mutex/sql/FILE_AS_TABLE::LOCK_shim_lists

引擎在跟踪打开的表的内部结构上执行以下操作(如 reset_sizedetach_contentsadd_contents)时获取此互斥。该互斥可同步对列表内容的访问。当此等待事件以高频发生时,它表示之前访问的表集突然发生变化。引擎需要访问新表或放弃与之前访问的表相关的上下文。

synch/mutex/sql/LOCK_open

会话打开的表数超过了表定义缓存或表打开缓存的大小。增加这些缓存的大小。有关更多信息,请参阅 MySQL 如何打开和关闭表

synch/mutex/sql/LOCK_table_cache

会话打开的表数量超过了表定义缓存或表打开缓存的大小。增加这些缓存的大小。有关更多信息,请参阅 MySQL 如何打开和关闭表

synch/mutex/sql/LOG

在该等待事件中,有正等待日志锁定的线程。例如,线程可能等待锁定写入慢速查询日志文件。

synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit

在该等待事件中,有正等待带着提交到二进制日志的意图获取锁定的线程。二进制日志记录争用可能出现在更改率非常高的数据库上。根据您的 MySQL 版本,有特定锁定用于保护二进制日志的一致性和持续性。在 RDS for MySQL 中,二进制日志用于复制和自动备份过程。在 Aurora MySQL 中,本机复制或备份不需要二进制日志。它们默认情况下处于禁用状态,但可以启用或用于外部复制或更改数据捕获。有关更多信息,请参阅 MySQL 文档中的二进制日志

sync/mutex/sql/MYSQL_BIN_LOG::LOCK_dump_thread_metrics_collection

如果打开了二进制日志记录,则当引擎将活动转储线程指标打印到引擎错误日志和内部操作映射时,将获得此互斥。

sync/mutex/sql/MYSQL_BIN_LOG::LOCK_inactive_binlogs_map

如果打开了二进制日志记录,引擎在添加、删除或搜索最新二进制日志文件后面的二进制日志文件列表时获取此互斥。

sync/mutex/sql/MYSQL_BIN_LOG::LOCK_io_cache

如果打开二进制日志记录,引擎将在以下 Aurora 二进制日志 IO 缓存操作期间获取此互斥:分配、调整大小、释放、写入、读取、清除和访问缓存信息。如果此事件频繁发生,则引擎在访问存储二进制日志事件的缓存。为了减少等待时间,请减少提交。尝试将多个语句分组到一个事务中。

synch/mutex/sql/MYSQL_BIN_LOG::LOCK_log

您已开启二进制日志记录。可能存在较高的提交吞吐量、很多事务提交或读取二进制日志的副本。考虑使用多行语句或将语句捆绑到一个事务中。在 Aurora 中,使用全局数据库而不是二进制日志复制,或使用 aurora_binlog_* 参数。

synch/mutex/sql/SERVER_THREAD::LOCK_sync

互斥锁 SERVER_THREAD::LOCK_sync 在调度、处理或启动线程以进行文件写入的过程中获取。此等待事件发生过多表示数据库中的写入活动增加。

synch/mutex/sql/TABLESPACES:lock

引擎在以下表空间操作期间获取 TABLESPACES:lock 互斥:创建、删除、截断和扩展。此等待事件发生过多表示表空间操作频率很高。例如,将大量数据加载到数据库中。

synch/rwlock/innodb/dict

在该等待事件中,有正等待 InnoDB 数据字典中保留的 rwlock 的线程。

synch/rwlock/innodb/dict_operation_lock

在该等待事件中,有在 InnoDB 数据字典操作中保留锁定的线程。

synch/rwlock/innodb/dict sys RW lock

同时触发数据定义语言代码 (DDL) 中的大量并发数据控制语言语句 (DCL)。在常规应用程序活动期间,减少应用程序对 DDL 的依赖。

synch/rwlock/innodb/index_tree_rw_lock

大量类似的数据操作语言 (DML) 语句同时访问相同的数据库对象。尝试使用多行语句。此外,将工作负载分散到不同的数据库对象上。例如,实施分区。

synch/sxlock/innodb/dict_operation_lock

同时触发数据定义语言代码 (DDL) 中的大量并发数据控制语言语句 (DCL)。在常规应用程序活动期间,减少应用程序对 DDL 的依赖。

synch/sxlock/innodb/dict_sys_lock

同时触发数据定义语言代码 (DDL) 中的大量并发数据控制语言语句 (DCL)。在常规应用程序活动期间,减少应用程序对 DDL 的依赖。

synch/sxlock/innodb/hash_table_locks

会话在缓冲池中找不到页面。引擎要么需要读取文件,要么需要修改缓冲池的最近使用最少 (LRU) 列表。考虑增加缓冲区缓存大小并改进相关查询的访问路径。

synch/sxlock/innodb/index_tree_rw_lock

很多类似的数据操作语言 (DML) 语句同时访问相同的数据库对象。尝试使用多行语句。此外,将工作负载分散到不同的数据库对象上。例如,实施分区。

有关同步等待事件问题排查的更多信息,请参阅为什么我的 MySQL 数据库实例在 Performance Insights 中的 SYNCH 等待事件显示有大量活动会话正在等待?