为何已使用多列索引全部列，查询却未命中该索引？

架构老林

2026-5-25

这种情况我碰到过不少，咱们一步步来拆解可能的原因，帮你搞清楚为啥索引没被用上：

可能的原因分析

你创建的是(startTime, endTime)的联合索引，MySQL对联合索引的使用有严格的规则——必须遵循最左前缀匹配。简单来说：

查询条件里必须先用到startTime，如果先写endTime再写startTime，索引直接失效；
如果startTime被函数包裹（比如DATE(startTime) = '2024-01-01'），或者用了模糊查询的前缀匹配（startTime LIKE '%2024'），也会导致索引无法被正常使用；
要是startTime用了范围查询（比如startTime > '2024-01-01'），后面的endTime等值查询也无法利用到索引的后半段。

你的主查询核心条件是prog.asset IN (子查询)，这部分会极大影响优化器的选择：

如果子查询返回的asset ID数量特别多，优化器会认为：先通过子查询拿到所有ID，再全表扫描program表同时过滤时间和asset条件，比走idx_prog_time索引后再匹配大量asset ID的成本更低；
如果asset列本身重复值很多（基数低），优化器也会倾向于全表扫描，因为索引过滤的收益不明显。

MySQL优化器完全依赖表的统计信息来评估索引的效率，如果program表最近有大量数据插入、删除或修改，统计信息没及时更新，优化器可能会错误地判断「走索引不如全表扫描」。

如果你的startTime和endTime条件过滤后，返回的行数占表总行数的比例很高（比如超过30%），优化器通常会放弃索引。因为此时用索引需要先定位数据，再回表取行，来回折腾的IO成本比直接全表扫描更高。

如果startTime/endTime是datetime类型，但你查询时用了字符串格式的日期（比如startTime = '20240101'），或者用了不同类型的值进行比较，会触发MySQL的隐式类型转换，直接导致索引失效。

极少数情况下，索引可能因为表损坏、引擎异常（比如老旧的MyISAM引擎）等原因无法被正常识别，这时候重建索引就能解决问题。

先核对WHERE子句中startTime和endTime的写法，有没有违反最左前缀原则、函数包裹或类型不匹配的情况；
查看子查询返回的结果集大小，如果结果集很大，考虑把IN子查询改成JOIN，或者创建(asset, startTime, endTime)的联合索引（让优化器先按asset过滤，再用时间条件）；
执行ANALYZE TABLE program;更新表的统计信息，再重新运行EXPLAIN查看结果；
若想强制测试索引效果，可以添加FORCE INDEX(idx_prog_time)：
```
EXPLAIN SELECT prog.id FROM program prog FORCE INDEX(idx_prog_time) WHERE prog.asset IN (...) AND startTime ... AND endTime ...;
```
对比执行计划的成本，判断哪种方式更优；

尝试重建索引：

DROP INDEX idx_prog_time ON program;
CREATE INDEX idx_prog_time ON program (startTime, endTime);

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