在这个查询中，名为(key_part1, key_part2)的索引使得优化器可以避免排序:

SELECT * FROM t1
  ORDER BY key_part1, key_part2;

然而，该查询使用SELECT *，这可能会选择更多列，而不是key_part1和key_part2。在这种情况下，如果扫描整个索引并查找表行以找到不在索引中的列可能比扫描表并对结果进行排序更贵，优化器可能不会使用索引。如果SELECT *仅选择索引列，索引将被用于避免排序。

如果t1是一个InnoDB表，那么表的主键是隐式包含在索引中的，并且该索引可以用来解决ORDER BY为此查询:

SELECT pk, key_part1, key_part2 FROM t1
  ORDER BY key_part1, key_part2;

在这个查询中，key_part1是一个常量，所以通过索引访问的所有行都按key_part2顺序排列，并且名为(key_part1, key_part2)的索引避免了排序，如果WHERE子句足够选择性，使得索引范围扫描比表扫描便宜:

SELECT * FROM t1
  WHERE key_part1 = constant
  ORDER BY key_part2;

在接下来的两个查询中，是否使用索引与之前展示的相同查询类似，但不带有DESC:

SELECT * FROM t1
  ORDER BY key_part1 DESC, key_part2 DESC;

SELECT * FROM t1
  WHERE key_part1 = constant
  ORDER BY key_part2 DESC;

ORDER BY子句中的两个列可以以相同方向（都为ASC，或都为DESC）排序，也可以以相反方向排序（一个为ASC，另一个为DESC）。索引使用的条件是索引必须具有相同的同质性，但不必具有相同的实际方向。

如果查询混合了ASC和DESC，优化器可以使用名为(key_part1, key_part2)的索引的列，如果索引也使用了相应的混合升序和降序列:

SELECT * FROM t1
  ORDER BY key_part1 DESC, key_part2 ASC;

优化器可以使用名为(key_part1, key_part2)的索引，如果key_part1是降序，key_part2是升序。它也可以使用那些列的索引（进行反向扫描）如果key_part1是升序，key_part2是降序。请参阅第10.3.13节“Descending Indexes”。

在接下来的两个查询中，key_part1与常量进行比较。索引被用于WHERE子句足够选择性，使得索引范围扫描比表扫描便宜:

SELECT * FROM t1
  WHERE key_part1 > constant
  ORDER BY key_part1 ASC;

SELECT * FROM t1
  WHERE key_part1 < constant
  ORDER BY key_part1 DESC;

在下一个查询中，ORDER BY 不指定 key_部分1，但所有选出的行都有一个恒定的 key_部分1 值，因此索引仍然可以使用：

SELECT * FROM t1
  WHERE key_part1 = constant1 AND key_part2 > constant2
  ORDER BY key_part2;

查询使用了不同索引的 ORDER BY：

SELECT * FROM t1 ORDER BY key1, key2;

查询使用了非连续部分的索引进行 ORDER BY：

SELECT * FROM t1 WHERE key2=constant ORDER BY key1_part1, key1_part3;

用于检索行的索引与 ORDER BY 中使用的索引不同：

SELECT * FROM t1 WHERE key2=constant ORDER BY key1;

查询使用了包含除了索引列名之外的表达式的 ORDER BY：

SELECT * FROM t1 ORDER BY ABS(key);
SELECT * FROM t1 ORDER BY -key;

查询连接了许多表，ORDER BY 中的列不都是从第一个非常量表中检索行的表中来的。（这是在 EXPLAIN 输出中没有 const 连接类型的第一个表。）

查询有不同的 ORDER BY 和 GROUP BY 表达式。

只有索引列的前缀被索引。在这种情况下，索引不能完全解决排序顺序。例如，如果只对一个 CHAR(20) 列的前 10 个字节进行了索引，索引就不能区分超过第 10 个字节的值，因此需要 filesort。

索引不存储按顺序排列的行。例如，这是对一个 MEMORY 表中的 HASH 索引的真实情况。

增加sort_buffer_size变量值。理想情况下，值应该足够大，以便整个结果集都能放入排序缓冲区（避免写入磁盘和合并passes）。

注意，存储在排序缓冲区中的列值大小受到max_sort_length系统变量值的影响。例如，如果表元组存储长字符串列值，并且您增加了max_sort_length的值，排序缓冲区元组大小也会随之增加，这可能要求您增加sort_buffer_size。

为了监控合并passes（合并临时文件）的数量，请检查Sort_merge_passes状态变量。

增加read_ rnd_buffer_size变量值，以便一次读取更多行。

更改tmpdir系统变量的值，使其指向一个拥有大量免费空间的专用文件系统。该变量值可以列出几个路径，这些路径将按顺序使用；您可以利用这个特性来在多个目录之间分散负载。路径应该以Unix上使用的冒号字符（:）或Windows上使用的分号字符（;）分隔。路径应指向位于不同物理磁盘上的文件系统，不是同一磁盘上的不同分区。

如果EXPLAIN输出的Extra列不包含Using filesort，索引被使用了，没有进行filesort。

如果EXPLAIN输出的Extra列包含Using filesort，索引没有被使用，进行了filesort。

<sort_key, rowid>：这表示排序缓冲区中的元组是包含排序键值和原表行ID的对。元组按排序键值排序，使用行ID从表中读取行。

<sort_key, additional_fields>：这表示排序缓冲区中的元组包含排序键值和查询引用列的列。元组按排序键值排序，列值直接从元组中读取。

<sort_key, packed_additional_fields>：与前一种变体相同，但额外列紧凑排列而不是使用固定长度编码。