因为MySQL执行计划对一个表只使用一个索引。

如果 MySQL 使用范围扫描来 idx_firstval 满足列上的相等谓词 firstVal ，那么 MySQL 仍然需要检查 secondVal 列上的条件。

使用 AND ，MySQL 只需要检查索引范围扫描返回的行。需要检查的行集受条件约束。

使用 OR ，MySQL 需要检查索引范围扫描未返回的行，即表中所有其余行。没有索引，这意味着对表进行全扫描。如果我们对表进行全扫描以检查 secondVal ，那么检查扫描的两个条件将更便宜（即，包括索引访问和全扫描的计划将更昂贵。）

（如果有包含 firstVal 和 secondVal 的复合索引，那么对于查询 OR ，可以想象优化器可能会认为通过执行完整索引扫描来检查表中的所有行，然后查找数据页，其成本更低。）

当我们理解优化器可以使用哪些操作时，这将引导我们避免 OR 并重写查询，返回一个等效的结果集，使用一个更明确地定义两个集合组合的查询模式

SELECT a.*
  FROM the_table a
 WHERE a.firstVal = 'A'

UNION ALL

SELECT b.*
  FROM the_table b
 WHERE b.secondVal = 'B'
   AND NOT ( b.firstVal <=> 'A' )

（如果我们希望按特定顺序返回行，则添加 ORDER BY）

关于“如果存在包含 firstVal 和 secondVal 的复合索引 (...)”：我按照 @TimBiegeleisen 的建议检查了复合索引，OR 仍然会进行全表扫描，而不使用索引。这对我来说真的很奇怪；我认为优化器希望在两种情况下都使用此类索引，但对于分离查询则不需要。

对于简单集，全表扫描的成本很低，因此优化器可能更倾向于使用全表扫描的访问计划，而不是使用索引。如果使用索引的计划将访问索引中的页面和数据表中的页面……对于一个非常小的表，忽略索引并仅从表中获取页面的计划的成本估计较低，这并不奇怪。

如果 SELECT 列表中有 *，MySQL 将需要访问底层表中的数据页，以查找索引中不可用的任何列。如果查询的覆盖索引可用，我们更有可能看到索引被使用。它不会是范围扫描操作，因为它需要检查每一行，即完整扫描，但它可以在索引而不是表上进行扫描。尝试放弃 SELECT 列表中的 *，并让查询仅引用索引中可用的列，例如 SELECT t.firstVal, t.secondVal FROM the_table t WHERE ... OR ...

@spencer7593 我不认为这是完全正确的（一个表一个索引）。在我的例子中，我有一张非常大的表，我在其中执行 SELECT t.id, t.values FROM table t WHERE id IN (subquery1) OR id IN (subquery2) - 这是一个单一索引（在 id 上），并且足够大，索引可以带来巨大的改进，但 MySQL 仍然不使用它。

我很惊讶 MySQL 对这两个查询都使用了索引。这里要使用的正确索引是复合索引，它涵盖子句中的两列 WHERE ：

CREATE INDEX idx ON the_table (firstVal, secondVal);

至于为什么 MySQL 在第二种情况下使用索引，一种可能性可能是如果中的大多数记录的 the_table 值 firstVal 不是 。在这种情况下，仅仅知道相等性 A 为假就意味着该子句的整个结果 the_table.firstVal = 'A' 假 WHERE 基数 有关 。但无论如何，请考虑使用复合索引来覆盖所有基础。

您说得没错，“A”是该表中的罕见值（124 个条目），因此我进行了一些额外的查询以获取上下文。两个最常见的值（分别为 1747 个和 1446 个条目，称为“C”和“D”）都具有完全相同的 EXPLAIN。按照您的建议定义复合索引，AND 会切换到它，但 OR 仍然会进行全表扫描。

@Mew 我不知道您的实际数据或有多少条记录，但有时如果记录太少，SQL 数据库甚至不会使用索引。

@Mew：如果复合索引是查询的覆盖索引，我们可能会看到 OR 查询的完整索引扫描，如果查询中引用的所有列都包含在索引中。例如，在 SELECT 列表中放弃 * 并改为执行 SELECT firstVal, secondVal FROM the_table ...` 的查询（优化器不能使用范围扫描操作，它仍然需要检查每一行，但如果它可以完全从索引满足查询而不需要在底层表中查找页面，我们称之为查询的覆盖索引）。

@TimBiegeleisen：啊，也许我应该具体说明一下：the_table 中有 3436 行，正如我的帖子中第一个输出所显示的那样（在“rows”列中）。

这是一张很小的表。我猜索引在 OR 情况下不会有太大帮助，所以 MySQL 只能回退到表扫描。