MySQL索引未被选用问题咨询：7000万行表查询优化困惑

咱们先拆解一下你的问题：7000万条数据的表，查询条件是Year=? AND Quarter=? AND (user=? OR manager=? OR ...)，你建了两个索引都没被优化器选中——哪怕你预估用第一个索引只需要扫10%的数据。下面一步步分析可能的原因和解决办法：

一、先确认优化器的判断依据：统计信息是否过时 #

MySQL优化器选不选索引，核心是成本估算，而成本估算严重依赖表的统计信息。7000万条数据的表，如果很久没更新统计信息，或者数据有大量插入/删除，统计信息就会失真，导致优化器错误判断索引扫描的成本比全表扫描还高。

你可以先执行这个命令更新统计信息：

ANALYZE TABLE X;

更新完之后再用EXPLAIN看执行计划，看看索引会不会被选用。

二、OR条件的天然局限性：多字段OR很难高效利用联合索引 #

你建的Year+Quarter+所有用户相关字段的联合索引，其实对OR条件不友好。举个例子：

• 这个索引的排序逻辑是先按Year，再Quarter，再user，再manager...
• 当你用user=? OR manager=?时，优化器没法通过这个索引快速定位到所有符合条件的行——因为user和manager在索引里是按顺序排列的，匹配user的行和匹配manager的行在索引里是分散的，优化器需要多次扫描索引再合并结果，这个成本可能被估算得比全表扫描还高。

这也是为什么你建了这个索引依然没用的核心原因之一。

三、是否存在回表成本过高的问题 #

如果你的查询需要返回的字段不在索引里，就算优化器用了索引，也需要回表（通过主键去主键索引里拿数据）。7000万条数据的场景下，哪怕只扫10%的数据，回表的IO成本也可能非常高，优化器会觉得“不如直接全表扫”。

你可以检查：查询的所有字段是不是都包含在你建的联合索引里？如果不是，把需要返回的字段加到索引末尾（做成覆盖索引），这样优化器不需要回表，大概率会选用索引。

四、可行的解决方案 #

1. 拆分OR为UNION ALL（最推荐） #

把带有OR的查询拆成多个独立的子查询，用UNION ALL合并结果，比如：

SELECT 你需要的字段 FROM X 
WHERE Year=? AND Quarter=? AND user=?
UNION ALL
SELECT 你需要的字段 FROM X 
WHERE Year=? AND Quarter=? AND manager=?
UNION ALL
SELECT 你需要的字段 FROM X 
WHERE Year=? AND Quarter=? AND 其他用户字段=?;

然后给每个子查询单独建对应的联合索引：(Year, Quarter, user)、(Year, Quarter, manager)、(Year, Quarter, 其他用户字段)。这样每个子查询都能精准命中索引，效率会比单条OR查询高很多。

2. 强制索引测试，验证性能 #

如果确定用索引的性能更好，但优化器没选，可以用FORCE INDEX强制指定索引，看看实际执行效果：

SELECT 你需要的字段 FROM X 
FORCE INDEX(你的Year+Quarter联合索引名)
WHERE Year=? AND Quarter=? AND (user=? OR manager=? OR ...);

如果强制索引后性能确实提升，说明优化器的成本估算有误，你可以考虑调整优化器参数（比如optimizer_switch里的设置），但这个要谨慎，先做充分测试。

3. 检查MySQL版本 #

旧版本的MySQL（比如5.6及以前）对多字段OR的索引支持有限，如果你用的是比较老的版本，升级到5.7+或者8.0，优化器对这类场景的处理会更智能。

最后一步：用EXPLAIN排查细节 #

不管做什么调整，都要先用EXPLAIN看执行计划：

• 看key字段是不是你期望的索引
• 看rows字段，优化器预估的扫描行数和实际行数差距大不大
• 看Extra字段，有没有Using index（覆盖索引）、Using where等标识，帮助你判断优化器的执行逻辑

内容的提问来源于stack exchange，提问作者passionate