io/table/sql/handler - Amazon Aurora
支持的引擎版本上下文等待次数增加的可能原因操作

io/table/sql/handler

当工作被委派给存储引擎时，会发生 io/table/sql/handler 事件。

支持的引擎版本

以下引擎版本支持此等待事件信息：

  • Aurora MySQL 版本 3：3.01.0 和 3.01.1

  • Aurora MySQL 版本 2

上下文

事件 io/table 表示等待访问表。无论数据是缓存在缓冲池中还是可在磁盘上访问，都会发生此事件。io/table/sql/handler 事件表示工作负载活动增加。

处理程序是专门处理某种类型的数据或专注于某些特殊任务的例程。例如，事件处理程序接收和提取来自操作系统或用户界面的事件和信号。内存处理程序执行与内存相关的任务。文件输入处理程序是接收文件输入并根据上下文对数据执行特殊任务的函数。

performance_schema.events_waits_current 之类的视图在实际的等待是嵌套的等待事件（例如锁定）时经常显示 io/table/sql/handler。当实际的等待不是 io/table/sql/handler 是，性能详情将报告嵌套的等待事件。当性能详情报告 io/table/sql/handler 时，它表示 I/O 请求的 InnoDB 处理，而不是隐藏的嵌套等待事件。有关更多信息，请参阅 MySQL 参考手册中的性能架构“原子”和“分子”事件。

注意

但是，在 Aurora MySQL 版本 3.01.0 和 3.01.1 中，synch/mutex/innodb/aurora_lock_thread_slot_futex 将报告为 io/table/sql/handler。

io/table/sql/handler 事件通常显示在具有 io/aurora_redo_log_flush 和 io/file/innodb/innodb_data_file 之类的输入/输出等待的主要等待事件中。

等待次数增加的可能原因

在性能详情中，io/table/sql/handler 事件突然激增表示工作负载活动增加。活动增加意味着输入/输出增加。

当底层嵌套事件为锁定等待时，性能详情会筛选嵌套事件 ID，但不会报告 io/table/sql/handler 等待。例如，如果根本原因事件是 synch/mutex/innodb/aurora_lock_thread_slot_futex，性能详情会将此等待显示在主要等待事件中而不是 io/table/sql/handler 中。

在 performance_schema.events_waits_current 之类的视图中，当实际的等待是嵌套的等待事件（例如锁定）时经常显示 io/table/sql/handler 的等待。当实际等待与 io/table/sql/handler 不同时，性能详情会查找嵌套等待并报告实际等待而不是 io/table/sql/handler。当性能详情报告 io/table/sql/handler 时，实际的等待为 io/table/sql/handler，而不是隐藏的嵌套等待事件。有关更多信息，请参阅 MySQL 5.7 参考手册中的性能架构“原子”和“分子”事件。

注意

但是，在 Aurora MySQL 版本 3.01.0 和 3.01.1 中，synch/mutex/innodb/aurora_lock_thread_slot_futex 将报告为 io/table/sql/handler。

操作

如果此等待事件主导着数据库活动，它不一定表示性能问题。当数据库处于活动状态时，等待事件始终显示在最前面。您只需要在性能下降时采取行动。

根据您看到的其他等待事件，我们建议采取不同的操作。

确定导致事件的会话和查询

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

查找负责高负载的 SQL 查询

  1. 登录 AWS 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 Aurora MySQL 工作负载。

检查与性能详情计数器指标的关联性

检查性能详情计数器指标，如 Innodb_rows_changed。如果计数器指标与 io/table/sql/handler 相关，请按照以下步骤操作：

  1. 在性能详情中，查找负责 io/table/sql/handler 主要等待事件的 SQL 语句。如果可能，请优化此语句，使其返回的行更少。

  2. 从 schema_table_statistics 和 x$schema_table_statistics 视图中查看主要的表。这些视图显示了每个表花费的时间。有关更多信息，请参阅 MySQL 参考手册中的 schema_table_statistics 和 x$schema_table_statistics 视图。

    预设情况下，行按总等待时间降序排序。争用最多的表首先显示。输出表明时间是花在读取、写入、获取、插入、更新还是删除上。以下示例在 Aurora MySQL 2.09.1 实例上运行。

    mysql> select * from sys.schema_table_statistics limit 1\G

*************************** 1. row ***************************
     table_schema: read_only_db
       table_name: sbtest41
    total_latency: 54.11 m
     rows_fetched: 6001557
    fetch_latency: 39.14 m
    rows_inserted: 14833
   insert_latency: 5.78 m
     rows_updated: 30470
   update_latency: 5.39 m
     rows_deleted: 14833
   delete_latency: 3.81 m
 io_read_requests: NULL
          io_read: NULL
  io_read_latency: NULL
io_write_requests: NULL
         io_write: NULL
 io_write_latency: NULL
 io_misc_requests: NULL
  io_misc_latency: NULL
1 row in set (0.11 sec)

检查其他相关的等待事件

如果 synch/sxlock/innodb/btr_search_latch 和 io/table/sql/handler 是造成数据库加载异常的最大因素，检查 innodb_adaptive_hash_index 变量是否已开启。如果是，请考虑增加 innodb_adaptive_hash_index_parts 参数值。

如果自适应哈希索引已关闭，请考虑将其开启。要了解有关 MySQL 自适应哈希索引的更多信息，请参阅以下资源：

注意

Aurora 读取器数据库实例不支持自适应哈希索引。

在某些情况下，当 synch/sxlock/innodb/btr_search_latch 和 io/table/sql/handler 起主导作用时，读取器实例的性能可能较差。如果是这样，请考虑临时将工作负载重新导向到写入器数据库实例并开启自适应哈希索引。