synch/rwlock/innodb/hash_table_locks - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

synch/rwlock/innodb/hash_table_locks

如果修改映射缓冲区缓存的哈希表时存在争用现象,会发生 synch/rwlock/innodb/hash_table_locks 事件。

支持的引擎版本

Aurora MySQL 版本 1(最高 1.23.1)支持此等待事件信息。

上下文

事件 synch/rwlock/innodb/hash_table_locks 表示修改映射缓冲区缓存的哈希表时存在争用现象。哈希表是内存中专用于提高缓冲池访问性能的表。当哈希表需要修改时,会调用此等待事件。

有关更多信息,请参阅 MySQL 文档中的缓存池

等待次数增加的可能原因

synch/rwlock/innodb/hash_table_locks 事件的发生率超过正常(可能表示性能问题)时,典型原因包括以下几点:

缓冲池大小不足

缓冲池太小,无法将所有经常访问的页面保留在内存中。

繁重的工作负载

工作负载导致缓冲区缓存中频繁发生移出和数据页面重新加载操作。

操作

根据等待事件的原因,我们建议采取不同的操作。

增加缓冲池的大小

确保缓冲池的大小适合工作负载。为此,您可以检查缓冲池缓存命中率。通常,如果该值降至 95% 以下,请考虑增加缓冲池大小。较大的缓冲池可以将经常访问的页面在内存中保留更长时间。

要增加缓冲池的大小,请修改 innodb_buffer_pool_size 参数的值。该参数的原定设置值取决于数据库实例类的大小。有关更多信息,请参阅 Amazon 数据库博客文章为 Amazon RDS for MySQL 配置参数的最佳实践,第 1 部分:与性能相关的参数

改进数据访问模式

检查受此等待影响的查询及其执行计划。考虑改进数据访问模式。例如,如果您使用的是 mysqli_result::fetch_array,您可以尝试增加数组获取大小。

您可以使用性能详情来显示可能导致 synch/rwlock/innodb/hash_table_locks 等待事件的查询和会话。

查找负责高负载的 SQL 查询

通常,具有中等到大量负载的数据库都会有等待事件。如果性能最佳,等待事件可能是可以接受的。如果性能不佳,请检查数据库花费最多时间的位置。查看导致最高负载的等待事件,并了解是否可以优化数据库和应用程序以减少这些事件。

查找负责高负载的 SQL 查询

  1. 登录Amazon Web Services Management Console并通过以下网址打开 Amazon RDS 控制台:https://console.aws.amazon.com/rds/

  2. 在导航窗格中,选择 Performance Insights

  3. 选择一个数据库实例。将为该数据库实例显示性能详情控制面板。

  4. Database load(数据库负载)图表中,选择 Slice by wait(按等待切片)。

  5. 在页面底部,选择 Top SQL(主要 SQL)。

    该图表列出了负责加载的 SQL 查询。排在列表前面的负载负有最大的责任。为了解决瓶颈,请关注这些语句。

有关使用性能详情进行故障排除的有用概览,请参阅 Amazon 数据库博客文章使用性能详情分析 Amazon Aurora MySQL 工作负载

减少或避免完整的表扫描

监控您的工作负载以查看它是否正在运行完整的表扫描,如果是,则减少或避免它们。例如,您可以监控状态变量,例如 Handler_read_rnd_next。有关更多信息,请参阅 MySQL 文档中的服务器状态变量