MySQL 联合索引没有命中 怎样处理

MySQL 联合索引没有命中时，先不要急着强制使用索引。更稳妥的顺序是：看索引列顺序是否符合最左前缀，再检查条件中有没有范围、函数或类型转换，最后用 EXPLAIN 判断优化器是无法使用，还是认为全表扫描更便宜。联合索引“没有全部命中”与“完全没有用上”不是一回事。

把联合索引当成按列顺序排列的有序结构来理解：查询可以从最左列开始使用连续前缀，但不能跳过第一列直接从后缀列做普通索引查找。

• 先看顺序：索引 (tenant_id, status, created_at) 适合从 tenant_id 开始的条件。
• 再看条件：等值条件通常先固定索引范围，范围条件会影响后续列继续参与定位的能力。
• 最后看计划：possible_keys、key 和 key_len 能说明索引候选、实际选择和使用长度。

先按最左前缀检查索引顺序

假设表上有一个联合索引：

CREATE INDEX idx_orders_tenant_status_created
ON orders (tenant_id, status, created_at); /* 中文注释：按租户、状态、创建时间组织索引 */

MySQL 8.4 手册说明，多列索引可以支持全部列，也可以支持从第一列开始的连续前缀。因此下面的条件具备使用这个索引的结构基础：

SELECT id, status, created_at
FROM orders
WHERE tenant_id = 7
  AND status = 'ready'; /* 中文注释：固定前两列，保留最左连续前缀 */

SELECT id, status, created_at
FROM orders
WHERE tenant_id = 7
  AND status = 'ready'
  AND created_at >= '2026-10-01'; /* 中文注释：最后一列使用范围，仍从最左列开始 */

反过来，只写 status，或者写 status 与 created_at，都跳过了第一列 tenant_id。这时虽然 WHERE 中出现了索引列，但不代表这个联合索引能按普通查找路径定位记录。如果业务最常见的查询确实只按状态筛选，就要重新评估是否需要一个以 status 开头的独立索引，而不是把现有联合索引当成万能索引。

再拆解等值、范围和表达式

列顺序正确后，还要看每个条件的形状。一个常见的列表查询可以写成：

SELECT id, status, created_at
FROM orders
WHERE tenant_id = 7
  AND status = 'ready'
  AND created_at >= '2026-10-01'
ORDER BY created_at DESC
LIMIT 20; /* 中文注释：等值条件先缩小范围，时间条件负责筛选最近数据 */

这里的 tenant_id 和 status 是等值条件，created_at 是范围条件，并且它已经放在索引末端，通常比把范围列放在后面更符合这个查询形状。若在范围列后面再放一个需要继续精确定位的列，后续列的索引收益可能无法按预期发挥，不能只看“列都写进索引了”就认为一定有效。

下面几类写法也经常让索引利用率下降：

SELECT id
FROM orders
WHERE DATE(created_at) = '2026-10-22'; /* 中文注释：对索引列包函数，改成半开区间更容易保留范围能力 */

SELECT id
FROM orders
WHERE customer_code LIKE '%A12'; /* 中文注释：前导通配符无法从字符串开头建立连续查找范围 */

SELECT id
FROM orders
WHERE tenant_id = '7'; /* 中文注释：参数类型应与列类型一致，避免隐式转换改变计划 */

第一种可以改成 created_at >= '2026-10-22' AND created_at ；第二种要根据业务考虑前缀搜索、专门的检索方案或接受扫描；第三种则应让绑定参数与字段类型一致。改写的目标不是让 key 一定出现，而是让优化器看见真实、连续且有选择性的查找范围。

用 EXPLAIN 判断到底是哪一类问题

先对原 SQL 做计划检查，不要凭经验猜：

EXPLAIN
SELECT id, status, created_at
FROM orders
WHERE tenant_id = 7
  AND status = 'ready'
  AND created_at >= '2026-10-01'
ORDER BY created_at DESC
LIMIT 20; /* 中文注释：先观察优化器选择，不直接添加 FORCE INDEX */

重点看五个字段：

• possible_keys：优化器认为可能参与的索引候选。
• key：这一次实际选择的索引；为 NULL 时表示没有选索引。
• key_len：实际使用的索引长度，可辅助判断联合索引使用到哪一段。
• rows 与 filtered：估算需要检查的行数和过滤比例，用来判断扫描代价。
• Extra：补充说明，例如是否还需要额外过滤或排序。

如果 possible_keys 就没有目标联合索引，优先回到 SQL 条件和索引定义；如果 possible_keys 有它但 key 为空，可能是选择性不足、表很小、估算成本偏高，或统计信息不能反映当前数据分布。此时不要把“没有命中”直接等同于“索引失效”。

按查询形状修正，而不是盲目加索引

可以按下面的决策顺序处理：

1. 查询是否总从同一列开始？如果不是，按真实高频查询形状重新设计列顺序。
2. 是否对索引列使用了函数、隐式类型转换或前导通配符？先改写表达式或调整参数类型。
3. 等值列、范围列和排序列是否符合当前查询？不要只按“区分度最高”机械排序。
4. 统计信息是否明显滞后？在确认表数据变化较大后，再安排 ANALYZE TABLE，并重新查看计划。
5. 优化器是否只是认为全表扫描更便宜？保留计划证据，结合实际数据量和线上查询耗时决定是否需要改索引。

ANALYZE TABLE orders; /* 中文注释：数据分布明显变化后更新优化器统计信息 */

只有在查询形状、列类型和统计信息都合理后，才考虑新建索引或使用提示语句。提示可以帮助定位实验，但不应掩盖索引列顺序、数据分布和 SQL 表达式本身的问题。

常见问题

联合索引只命中第一列，算不算没有命中？

不算。只要使用了最左连续前缀，就可能已经利用了联合索引的一部分；应结合 key_len 和 rows 判断这部分收益是否足够。

EXPLAIN 的 key 为 NULL 就一定要加索引吗？

不一定。表很小、条件选择性低或全表扫描成本更低时，优化器可能主动不选索引。先看 possible_keys、估算行数和查询边界，再决定是否改动。

把所有查询字段都放进联合索引可以吗？

不建议。索引会增加写入和存储成本，也会受到列顺序、范围条件和排序需求限制。应从真实高频查询形状出发，设计有限且可解释的索引。