创建排序索引 - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

创建排序索引

creating sort index 线程状态表示线程正在处理要求使用内部临时表对数据进行排序的 SELECT 语句。

支持的引擎版本

以下版本支持此线程状态信息:

  • Aurora MySQL 版本 2,最高 2.09.2

  • Aurora MySQL 版本 1,最高 1.23.1

Context

当具有 ORDER BYGROUP BY 子句的查询不能使用现有索引来执行操作时,将出现 creating sort index 状态。在这种情况下,MySQL 需要执行更昂贵的 filesort 操作。如果结果集不太大,通常在内存中执行此操作。否则,它涉及在磁盘上创建文件。

等待次数增加的可能原因

creating sort index 的外观本身并不表明存在问题。如果性能不佳,且您看到频繁的 creating sort index 实例,最有可能的原因是使用 ORDER BYGROUP BY 运算符进行的查询缓慢。

Actions

一般指南是查找带有与 creating sort index 状态增加相关的 ORDER BYGROUP BY 子句的查询。然后看看是添加索引还是增加排序缓冲区大小解决了问题。

如果性能架构未开启,请打开它

仅在性能架构工具未打开时,性能详情才会报告线程状态。启用性能架构工具后,性能详情会报告等待事件。在调查潜在的性能问题时,性能架构工具可以提供更多洞察和更好的工具。因此,建议您开启性能架构。有关更多信息,请参阅 为 Aurora MySQL 上的 Performance Insights 启用性能架构

识别问题查询

要识别导致增加 creating sort index 状态增加的当前查询,请运行 show processlist 并了解是否有任何查询为 ORDER BYGROUP BY。或者,请运行 explain for connection N,其中 N 是具有 filesort 的查询的进程列表 ID。

要识别导致这些增加的过去查询,请打开慢查询日志并查找具有 ORDER BY 的查询。在慢查询上运行 EXPLAIN 并查找“using filesort”。有关更多信息,请参阅 检查文件排序使用的解释计划

检查文件排序使用的解释计划

识别具有导致 creating sort index 状态的 ORDER BYGROUP BY 子句的语句。

以下示例显示了如何运行在查询上运行 explainExtra 列显示此查询使用 filesort

mysql> explain select * from mytable order by c1 limit 10\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: mytable partitions: NULL type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 2064548 filtered: 100.00 Extra: Using filesort 1 row in set, 1 warning (0.01 sec)

以下示例显示了在列 c1 上创建索引后在同一查询上运行 EXPLAIN 的结果。

mysql> alter table mytable add index (c1);
mysql> explain select * from mytable order by c1 limit 10\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: mytable partitions: NULL type: index possible_keys: NULL key: c1 key_len: 1023 ref: NULL rows: 10 filtered: 100.00 Extra: Using index 1 row in set, 1 warning (0.01 sec)

有关使用索引进行排序顺序优化的信息,请参阅 MySQL 文档中的 ORDER BY 优化

提高排序缓冲区大小

要查看特定查询是否需要在磁盘上创建文件的 filesort 进程,请在运行查询后检查 sort_merge_passes 变量值。下面是一个示例。

mysql> show session status like 'sort_merge_passes'; +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | Sort_merge_passes | 0 | +-------------------+-------+ 1 row in set (0.01 sec) --- run query mysql> select * from mytable order by u limit 10; --- run status again: mysql> show session status like 'sort_merge_passes'; +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | Sort_merge_passes | 0 | +-------------------+-------+ 1 row in set (0.01 sec)

如果 sort_merge_passes 的值很高,请考虑增加排序缓冲区的大小。在会话级别应用增加,因为在全局范围内增加它可以显著增加 RAM MySQL 的使用量。以下示例说明如何在运行查询之前更改排序缓冲区的大小。

mysql> set session sort_buffer_size=10*1024*1024; Query OK, 0 rows affected (0.00 sec) -- run query