MySQL 复合索引为什么没走：最左匹配、范围条件与排序顺序怎么查

订单列表突然变慢时，看到 SQL 上有“联合索引”并不等于 MySQL 一定会完整使用它。更可靠的判断方式是看 EXPLAIN 中的 key、key_len、type 和 Extra，确认优化器实际走到了复合索引的哪一段，以及排序是否另走了一条路径。

复合索引没有按预期生效，通常不是“索引失效”四个字能解释的：先核对字段顺序，再看第一个范围条件是否截断后续列，最后检查 ORDER BY 是否与已固定的索引前缀保持一致。

先用 EXPLAIN 还原实际访问路径

假设订单表有一个复合索引 idx_user_status_created，字段顺序是 user_id, status, created_at：

CREATE INDEX idx_user_status_created
ON orders (user_id, status, created_at);

EXPLAIN
SELECT id, status, created_at
FROM orders
WHERE user_id = 42
  AND status = 'paid'
  AND created_at >= '2026-08-01'
ORDER BY created_at DESC
LIMIT 20;

先看 key 是否为 idx_user_status_created。如果 key 为空，才是没有选择这个索引；如果 key 已命中，就继续看 key_len 和 Extra。type 为 ref 或 range 也不能单独代表好坏，关键是扫描范围是否符合这条查询的业务选择性。

最左匹配不是口诀，而是连续访问条件

这棵索引先按 user_id 排，再按 status 排，最后才按 created_at 排。查询若跳过第一列，例如只写 WHERE status = 'paid'，优化器很难把这棵索引当成一个窄范围入口。即使执行计划选择了索引，也可能只是扫描索引后再过滤，收益未必理想。

更容易误判的是范围条件：

EXPLAIN
SELECT id
FROM orders
WHERE user_id = 42
  AND status = 'paid'
  AND created_at >= '2026-08-01'
  AND id > 100000;

这里 user_id 和 status 先把入口缩小，created_at 进入范围扫描后，索引后续列通常不能再像等值条件那样继续切分范围。不要只看到三个字段都写在 WHERE 中，就断言三个字段都同等发挥了索引过滤作用。

ORDER BY 为什么仍然出现 Using filesort

WHERE 命中 idx_user_status_created 后，排序能否复用索引，还要看等值条件固定了哪些前缀，以及排序列是否沿着索引剩余顺序排列。下面这条查询固定了 user_id，但没有固定 status：

EXPLAIN
SELECT id, user_id, status, created_at
FROM orders
WHERE user_id = 42
ORDER BY created_at DESC
LIMIT 20;

同一个 user_id 下仍然混着多个 status 值，索引中的实际顺序是先 status、再 created_at，不能直接把所有结果按 created_at 连续取出，因此 Extra 可能出现 Using filesort。这不是磁盘一定发生了排序，而是 MySQL 需要额外的排序步骤；应结合返回行数和实际耗时判断。

如果业务确实经常按用户和状态筛选，再按创建时间倒序取最近订单，原来的索引顺序更匹配：

EXPLAIN
SELECT id, status, created_at
FROM orders
WHERE user_id = 42
  AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

这时两个前缀列都是等值条件，created_at 位于已固定前缀之后，优化器更有机会直接沿索引顺序取数。是否真的消除了排序，仍以当前版本、数据分布和完整 EXPLAIN 输出为准。

改索引前先排除三个误区

把 key_len 当成“用了几个字段”

key_len 是字节长度，不同字段类型、字符集和是否允许 NULL 都会影响它。用表结构计算一个大致值，再和执行计划对照；不要拿两个不同索引的 key_len 直接比较优劣。

看到 Using filesort 就立刻加索引

小结果集排序可能比维护一棵新索引更便宜。先记录扫描行数、返回行数和实际耗时，再判断是改写 ORDER BY、调整字段顺序，还是接受排序成本。

只在空表上验证

优化器会根据统计信息和估算选择路径。用接近生产的数据量验证，必要时在结构变更后更新统计信息，再比较同一条 SQL 的执行计划。

一套可重复的核对顺序

1. 确认查询没有对索引列做隐式类型转换或函数包装。
2. 按索引定义顺序标出 WHERE 中的等值条件、范围条件和缺失列。
3. 对照 key、key_len、rows、filtered 与 Extra。
4. 单独检查 ORDER BY 是否跨过未固定的索引列，是否因此产生排序。
5. 用真实数据重复 EXPLAIN，并记录改动前后的扫描行数与耗时。

相关问题

复合索引字段越多越好吗？

不是。字段越多，写入维护和存储成本越高，应围绕稳定的查询条件、排序和覆盖需求设计。

强制使用索引能解决 key 为空吗？

FORCE INDEX 只能改变一次选择，不能修复字段顺序、低选择性或统计信息问题，使用前要有执行计划证据。

MySQL 8.0 如何进一步确认排序和扫描？

可以在可控环境使用 EXPLAIN ANALYZE 对比估算与实际执行，但要注意它会真正执行语句，写操作必须先改成安全的只读验证方案。

小结

排查复合索引时，把“有没有索引”拆成三个问题：入口是否从最左列开始，范围条件在哪一列截断了后续利用，排序是否能沿着剩余索引顺序完成。用这三个问题去读 EXPLAIN，比盯着“索引已创建”更接近真实执行路径。