返回某些列时不使用 MySQL 索引

Question

我有一个带有 created_on 字段的表，该字段由自身编制索引。当查看一个慢查询时，我意识到根据我返回的列不使用索引。在以下两个示例中，我有 foo 和 bar 列。

• foo 是具有其他三列的另一个索引的一部分。
• bar 根本没有被编入索引。

---

EXPLAIN SELECT created_on, foo FROM T1
WHERE created_on > NOW() - INTERVAL 5 DAY;

未使用索引，搜索了 +3 百万行。 (Using where)

如果我添加一个LIMIT 子句，它将使用索引。

EXPLAIN SELECT created_on, foo FROM T1
WHERE created_on > NOW() - INTERVAL 5 DAY
LIMIT 1000;

---

如果使用另一列 bar 它也将使用索引。

EXPLAIN SELECT created_on, bar FROM T1
WHERE created_on > NOW() - INTERVAL 5 DAY;

使用了索引，只搜索了 150 万行。 (Using where; Using index)

为什么 MySQL 会跳过这些查询之一的索引？

Answer 1

EXPLAIN 输出的Extra 列中的“使用索引”表示查询已通过覆盖索引 得到满足，无需在基础表中查找数据页。 p>

对于第一个查询，这意味着 MySQL 使用的索引包含查询中引用的T1 中的所有列，即foo 和created_on。

（如果created_on 是索引中的前导列，则没有给出指示，允许 MySQL 使用范围扫描操作来快速消除大量行，或者 MySQL 是否正在检查索引中的每个条目，进行全索引扫描。我们需要更仔细地查看EXPLAIN 输出中的其他列。）

---

使用为第二个查询显示的EXPLAIN（EXPLAIN 输出中没有“使用索引”），我们推断没有同时包含bar 和created_on 的索引。

因此 MySQL 将不得不访问基础表中的页面，以获取其中一些列的值。

现在的问题是使用索引来缩小需要查看的行是否会更便宜（更快），或者扫描整个表是否更快。

---

通常，当我们说 MySQL“使用索引”时，我们指的不是覆盖索引。我们通常指的是 range 扫描操作或 ref 查找操作。我们通常说 MySQL 有效地利用了索引，显着减少了需要检查的行数或行数；通过非常有效地消除大量不需要检查的行来快速缩小所需的行。

要确定是否正在使用索引，我们查看 EXPLAIN 输出中的 key、keylen 和 ref 列。 （当 Extra 列中没有“使用索引”时，这并不意味着 MySQL 没有“使用索引”。）

---

更直接地回答所提出的问题：

问： 为什么 MySQL 会跳过这些查询之一的索引？

答： 当 MySQL 优化器确定有合适的索引可用时，并且当使用索引的执行计划是最低的估计成本时，MySQL 优化器将选择使用索引的执行计划。它考虑的所有计划。优化器可能会确定不使用索引的计划具有较低的估计成本。

添加合适的索引可以极大地影响 SQL 性能，因为它可以为优化器提供更高效的操作。

鉴于我们可以通过添加合适的索引来提升性能，我们对性能不佳的下意识反应是“添加索引”是可以理解的。

但添加索引并不是“灵丹妙药”。我们需要谨慎使用不会禁用 MySQL 使用索引能力的 SQL 构造，并且我们还需要仔细考虑哪些索引是最优的，不仅仅是针对单个语句，还要考虑整个 SQL 工作负载。

这个答案几乎没有触及 MySQL“使用索引”的主题。

为了完整起见，我们还应该注意（冒着不必要地弄脏水的风险）MySQL 优化器的行为受可用统计数据、一些系统变量的设置（尤其是optimizer_switch）以及SQL 文本中包含优化器“提示”。

Answer 2

SELECT created_on, foo FROM T1
WHERE created_on > NOW() - INTERVAL 5 DAY;

优化器可能会也可能不会使用INDEX(created_on)。这取决于过去 5 天内创建的行占表的百分比。将使用一小部分（例如，低于 20%）的索引。

另一方面，INDEX(created_on, foo)（按此顺序）因为它将“覆盖”。

foo 是具有其他三列的另一个索引的一部分。

索引中列的顺序非常很重要。如需进一步讨论，请提供SHOW CREATE TABLE。

如果使用另一个列栏，它也将使用索引。

该索引可能是PRIMARY KEY。如果您需要进一步讨论，请提供SHOW CREATE TABLE。

（使用位置；使用索引）

“使用索引”表示所有必要的列都在索引中。因此，只需要查看索引的 BTree。每个二级索引都隐含地包含 PRIMARY KEY 列。所以，我推断你有INDEX(bar) 并且 created_at 在PRIMARY KEY 的某个地方。

为什么 MySQL 会跳过这些查询之一的索引？

优化器会询问哪个更快（通常会给出正确答案）：

• 索引是“覆盖”，所以我们只使用索引。
• 让我们使用索引，但在它与数据的 BTree 之间跳转以获取其他一些列。
• 我不能用WHERE 做很多事情，但我可以使用ORDER BY 的索引；让我们这样做，并希望我不必扫描太多行。
• 平底船。让我们忽略所有索引并简单地扫描数据，丢弃任何与WHERE 子句不匹配的行。

是的，最后一个选项通常是最快的。一些可能的特征：

• 没有二级索引对WHERE 有很大帮助。
• 有一个WHERE，但它不会消除很多行。
• 没有ORDER BY，或者没有与之匹配的索引。
• 没有LIMIT。

如果使用 MySQL，EXPLAIN FORMAT=JSON SELECT ... 将提供它为做出决定所做的“基于成本”的计算。

我的cookbook 帮助构建最佳索引。