MySQL 复合索引跳过最左列时的访问边界

MySQL 复合索引跳过最左列时，不能简单地说“索引失效”。更准确的判断是：普通 B+Tree 定位遵循左前缀，缺少第一列条件时，通常不能把第二列直接当作连续范围的起点；但 MySQL 8.4 在满足成本和数据分布条件时，可能选择 Skip Scan，对第一列的不同值进行多次范围访问。因此，最终结论要以执行计划为准。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

一、先从索引顺序判断访问前缀

先用一个订单查询场景说明边界。复合索引把多个字段按固定顺序组织起来，查询能够稳定利用的通常是从第一列开始的连续前缀。

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  tenant_id BIGINT NOT NULL,
  status VARCHAR(20) NOT NULL,
  created_at DATETIME NOT NULL,
  amount DECIMAL(12, 2) NOT NULL,
  KEY idx_tenant_status_created (tenant_id, status, created_at)
);

-- 先命中最左列，status 可以继续作为同一索引前缀的一部分
SELECT id, amount
FROM orders
WHERE tenant_id = 42 AND status = 'paid';

-- 跳过 tenant_id，status 不再是普通左前缀的起点
SELECT id, amount
FROM orders
WHERE status = 'paid';

第一条查询至少给出了 tenant_id，优化器可以沿着索引的前缀缩小范围。第二条只给出 status，却没有告诉索引树第一层如何定位，因此不能把 status 当成一个天然连续的起点。若再加上 created_at，也不会自动跳过缺失的 tenant_id 把后两列拼成普通范围。

这里还要区分“能用索引”和“能高效定位”。即使查询最终选择了这个索引，也可能是较宽的索引扫描，再对 status 做过滤；如果查询还要读取未包含在索引里的列，随后还会发生回表。

二、用 EXPLAIN 识别真实访问方式

不要只看 possible_keys。它只表示某个索引可能参与优化，真正需要关注的是本次计划选了什么访问类型、预计扫描多少行，以及 Extra 暗示了什么。

-- 用执行计划观察跳过最左列后的实际访问方式
EXPLAIN
SELECT id, amount
FROM orders
WHERE status = 'paid' AND created_at >= '2026-01-01';

-- 对照完整左前缀查询，便于比较 key、type 和 rows
EXPLAIN
SELECT id, amount
FROM orders
WHERE tenant_id = 42
  AND status = 'paid'
  AND created_at >= '2026-01-01';

重点字段可以按下面的顺序阅读：

MySQL 8.4 手册给出的 Skip Scan 场景说明了一个重要例外：当第一列没有条件时，优化器可以针对第一列的不同取值进行多次范围扫描。它是成本模型的选择，不是“只要跳过第一列就一定能用”的承诺；第一列的基数、数据量、统计信息和查询返回规模都会影响决定。

三、围绕查询任务调整索引

如果业务中大量查询都是“按状态和时间找订单”，而租户条件并不稳定，就应评估更贴合任务的索引，而不是期待现有索引永远通过 Skip Scan 承担这类访问。

-- 为稳定的 status + created_at 过滤模式提供直接前缀
CREATE INDEX idx_status_created ON orders (status, created_at);

-- 重新查看计划，确认新索引是否真的降低了估算扫描范围
EXPLAIN
SELECT id, amount
FROM orders
WHERE status = 'paid'
  AND created_at >= '2026-01-01';

这个调整不是越多索引越好。新索引会占用空间，也会增加插入、更新和删除时的维护成本。若大多数请求都带 tenant_id，原来的顺序可能更合适；若状态值只有少数几种，单独把 status 放在第一列也未必选择性足够。索引顺序要由真实过滤条件、排序需求、返回列和数据分布共同决定。

还有两种比“直接加索引”更克制的处理：一是让上层查询在可行时补上租户等值条件，二是把跨租户统计拆成专门的查询路径。不要为了强行命中索引使用 FORCE INDEX，除非已经用稳定数据和回归计划证明优化器的默认选择有问题。

四、把访问边界写进检查清单

在上线或重构前，可以按下面四项复核：

1. 列顺序：查询是否提供了复合索引的最左连续前缀，范围条件是否过早截断了后续列。
2. 计划证据：key、type、rows 和 Extra 是否与预期一致，是否只是看到了 possible_keys。
3. 数据边界：第一列基数、状态分布、时间范围和返回行数变化后，Skip Scan 是否仍然划算。
4. 维护成本：新索引是否覆盖一个稳定查询族，是否会给写入、空间和统计信息维护带来额外负担。

最终要记住：跳过最左列并不等于“索引绝对失效”，也不等于“优化器一定会补救”。普通左前缀规则决定了默认访问边界，Skip Scan 提供了版本相关的成本型例外，EXPLAIN 才是判断当前 SQL 的入口。

相关问题

复合索引只给第二列条件时，为什么可能仍然看到 key？

优化器可能选择索引扫描、覆盖索引过滤或 Skip Scan。看到 key 只说明索引参与了计划，不能单独证明查询获得了精准范围定位。

把第二列移到索引第一列就一定更快吗？

不一定。要结合第一列和第二列的基数、常见查询条件、排序与回表情况，用代表性数据对比 EXPLAIN 和实际耗时。

Skip Scan 可以替代专用索引吗？

它更适合作为优化器在特定数据分布下的访问选择。若某个过滤模式稳定且频繁，仍应评估以该模式为左前缀的专用索引。