如果 ASC 和 DESC 混合使用，为什么 MySQL 不能为 ORDER BY 使用索引？

Question

假设我有一个非常简单的表格，如下所示：

CREATE TABLE `t1` (
  `key_part1` INT UNSIGNED NOT NULL,
  `key_part2` INT UNSIGNED NOT NULL,
  `value` TEXT NOT NULL,
  PRIMARY KEY (`key_part1`, `key_part2`)
) ENGINE=InnoDB

使用这个表，我想发出这样的查询：

SELECT *
FROM `t1`
ORDER BY `key_part1` ASC, `key_part2` DESC
LIMIT 1

我曾希望这个查询中的ORDER BY 会被索引所满足。不过根据MySQL documentation：

在某些情况下，MySQL 无法使用索引来解析ORDER BY，尽管它仍然使用索引来查找与WHERE 子句匹配的行。这些案例包括：

• 你把ASC和DESC混在一起：

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

我尝试了与上述查询类似的查询，正如预期的那样，EXPLAIN 输出表明这样的查询执行文件排序。这对我来说并不完全有意义，因为我可以执行以下操作：

SELECT *
FROM `t1`
WHERE `key_part1` = (
    SELECT `key_part1`
    FROM `t1`
    ORDER BY `key_part1` ASC
    LIMIT 1
)
ORDER BY `key_part2` DESC
LIMIT 1

当我EXPLAIN 这个时，它说子查询和外部查询都不使用文件排序。此外，我尝试了这种结构类似的技巧大表，发现它使我的查询速度提高了 3 个数量级。

我的问题是

1. 我在此处显示的两个查询是否相同？他们似乎是，但我可能遗漏了一些东西。如果不是，我的表中需要什么样的数据才能使它们给出不同的结果？
2. 是否有原因导致 MySQL 无法自行执行此优化技巧，或者这只是可能的优化案例，但尚未写入 MySQL？

如果重要的话，我使用的是 MySQL 5.6.22。

进一步说明：

“等效”是指“产生相同的结果”。此外，我非常清楚，如果我将 LIMIT 1 更改为 LIMIT 2 或其他内容，查询将不再产生相同的结果。 我对那些情况不感兴趣，只对LIMIT 1的情况感兴趣。

Answer 1

并不是说 MySQL 缺少优化“技巧”，而是复合索引如何工作的特性。 MySQL 一次只能在一个方向上进行索引扫描，并且必须与索引的排序方式一致（因此它可以进行计算机科学方面的事情，例如二进制搜索等）。

让我们看看您的示例查询：

选择 * 来自t1 在哪里key_part1 = ( 选择key_part1 来自t1 订购key_part1 ASC 限制 1 ) 通过key_part2 DESC 订购 限制 1 个

这可以在 key_part2 上排序，因为所有返回的行都将具有相同的 key_part1。所以基本上mysql可以忽略索引的那部分；它在功能上与ORDER BY key_part1 DESC, key_part2 DESC 相同。 ORDER BY 在子查询中的方向无关紧要，因为它在子查询中。

编辑

要清楚，您的示例查询实际上如下所示：

选择 * 来自t1 WHERE key_part1 = #{某个值} 通过key_part2 DESC 订购 限制 1 个

#{some value} 是子选择的结果。现在应该清楚为什么这种排序不需要文件排序，因为您根本没有按key_part1 排序。其实没必要，因为所有返回的行都会有相同的key_part1。