MySQL会使用覆盖索引吗？

假设我有一个穷人的搜索引擎，我正在搜索一个产品表

select
  category_id
from products
where
  description like '%blue%'

我知道你一定在想什么。如果删除前导通配符，查询可以正确使用描述索引这不是我要问的。

如果我有以下索引，查询的性能会更好吗

IX_description (description, category_id)

我想它可以扫描索引，而不是整个表，但这不是解释告诉我的。如果删除前导通配符，解释中的“额外”字段会告诉我已覆盖，但如果我将其放回，则不会覆盖

既然我只访问category_id和description，尽管使用了不同的description，那么我不应该在这两种情况下都包括在内吗

编辑：

我刚刚意识到，正如我所写的，如果产品是多对一的category\u id，那么这个查询实际上没有太多的语义意义。因此，缺少了一个DISTINCT，它可以生成正确的索引

 IX_description (category_id, description)

---

事实上，这是有保障的。但是我仍然想知道为什么它没有像最初所说的那样被包含在场景中。

因为在like查询的两端都使用了通配符，所以MySQL通常没有必要使用索引。不管怎样，做一次完整的表格扫描也同样快

然而。。。这里应该可以进行索引扫描，所以我想知道它是否没有使用索引扫描，因为表上有更新。或者仅仅因为这可能是一个更糟糕的查询计划

---

有关仅索引扫描的更多信息，请关注：

为什么表扫描会同样快？索引扫描不是因为其较小的大小而快得多吗？大小实际上并不相关；您可以“跳过”整个表中不需要处理的部分/字节。@MarkCanlas:它还涉及到能够同时（按顺序）读取大量数据。如果它可以对表而不是索引进行完整的顺序扫描，那么它就不应该这样做。然而，在这种情况下，我猜查询规划者并不理解，但我不是MySQL专家。你能试试强制索引吗？我确实试过强制索引，但一开始它会让性能变差，这是非常令人惊讶的。经过一些修改后，索引最终被“捕获”，查询速度很快。但为什么它没有从一开始就开始是令人费解的部分。MySQL查询规划器有时可能非常愚蠢。。。在某些情况下，你真的必须强制索引。突然之间，我无法重新创建这个场景。查询引擎是不是太挑剔了？