synch/sxlock/innodb/hash_table_locks
当必须从存储中读取在缓冲池中找不到的页面时，会发生 synch/sxlock/innodb/hash_table_locks 事件。
支持的引擎版本
以下版本支持此等待事件信息：
-
Aurora MySQL 版本 2 和 3
上下文
事件 synch/sxlock/innodb/hash_table_locks 表示工作负载经常访问未存储在缓冲池中的数据。此等待事件与添加新页面和从缓冲池中移出旧数据有关。存储在缓冲池中的过时数据和新数据必须缓存，因此移出过时的页面以允许缓存新页面。MySQL 使用最近最少使用的 (LRU) 算法将页面从缓冲池中移出。工作负载试图访问尚未加载到缓冲池中的数据或已从缓冲池中移出的数据。
如果工作负载必须访问磁盘上的文件中的数据，或者从缓冲池的 LRU 列表中释放数据块或将数据块添加到缓冲池的 LRU 列表中，就会发生此等待事件。这些操作等待获取共享的排除锁 (SX-lock)。此 SX-lock 用于通过哈希表进行同步，哈希表是内存中的一个表，旨在提高缓冲池访问性能。
有关更多信息，请参阅 MySQL 文档中的缓存池
等待次数增加的可能原因
当 synch/sxlock/innodb/hash_table_locks 等待事件显示超出正常情况，可能表示性能问题，典型原因包括以下几点：
- 缓冲池大小不足
-
缓冲池太小，无法将所有经常访问的页面保留在内存中。
- 繁重的工作负载
-
工作负载导致缓冲区缓存中频繁发生移出和数据页面重新加载操作。
- 读取页面时出错
-
读取缓冲池中的页面存在错误，这可能表明数据损坏。
操作
根据等待事件的原因，我们建议采取不同的操作。
增加缓冲池的大小
确保缓冲池的大小适合工作负载。为此，您可以检查缓冲池缓存命中率。通常，如果该值降至 95% 以下，请考虑增加缓冲池大小。较大的缓冲池可以将经常访问的页面在内存中保留更长时间。要增加缓冲池的大小，请修改 innodb_buffer_pool_size 参数的值。该参数的原定设置值取决于数据库实例类的大小。有关更多信息，请参阅 Amazon Aurora MySQL 数据库配置的最佳实践
改进数据访问模式
检查受此等待影响的查询及其执行计划。考虑改进数据访问模式。例如，如果您使用的是 mysqli_result::fetch_array
您可以使用性能详情来显示可能导致 synch/sxlock/innodb/hash_table_locks 等待事件的查询和会话。
查找负责高负载的 SQL 查询
登录 AWS Management Console 并通过以下网址打开 Amazon RDS 控制台：https://console.aws.amazon.com/rds/
。 -
在导航窗格中，选择 Performance Insights。
-
选择一个数据库实例。将为该数据库实例显示性能详情控制面板。
-
在 Database load（数据库负载）图表中，选择 Slice by wait（按等待切片）。
-
在页面底部，选择 Top SQL（主要 SQL）。
该图表列出了负责加载的 SQL 查询。排在列表前面的负载负有最大的责任。为了解决瓶颈，请关注这些语句。
有关使用性能详情进行故障排除的有用概览，请参阅 AWS 数据库博客文章使用性能详情分析 Amazon Aurora MySQL 工作负载
减少或避免完整的表扫描
监控您的工作负载以查看它是否正在运行完整的表扫描，如果是，则减少或避免它们。例如，您可以监控状态变量，例如 Handler_read_rnd_next。有关更多信息，请参阅 MySQL 文档中的服务器状态变量
检查错误日志是否有页面损坏
您可以检查 mysql-error.log 是否有在问题出现时检测到的与损坏相关的消息。错误日志中会显示您可以用来解决问题的消息。您可能需要重新创建报告为已损坏的对象。
