MySQL 8.4 Skip Scan 实战：复合索引没写左前缀，优化器为什么还可能走索引

很多人学 MySQL 复合索引，第一句就是左前缀原则：索引是 (region_id, user_id)，查询只有 user_id，那就用不上。这个判断大多数时候没错，但在 MySQL 8.x 的优化器里，还有一个容易被忽略的访问路径：Skip Scan。

Skip Scan 不是推翻左前缀原则。它更像优化器帮你做了一轮枚举：当前导列不同值很少，后续列过滤性又不错时，优化器可以枚举前导列的每个值，再在复合索引里跳到对应范围查后续列。用得好能避免全表扫，用不好也可能只是把扫描方式换得更绕。

先看一个真实业务场景

订单表有一个索引 idx_region_user(region_id, user_id)。最早业务都是按地区查用户订单，后来客服系统直接按用户查订单：

SELECT *
FROM orders
WHERE user_id = 10086
ORDER BY created_at DESC
LIMIT 20;

如果 region_id 只有几十个值，而 user_id 选择性很强，MySQL 可能不会直接全表扫描，而是对每个 region_id 值尝试在复合索引里查 user_id。这就是 Skip Scan 的典型机会。

怎么确认是不是 Skip Scan

不要靠感觉判断，先看执行计划。MySQL 的 EXPLAIN、EXPLAIN ANALYZE 和 optimizer_trace 都能帮助你确认优化器到底做了什么。

EXPLAIN FORMAT=TREE
SELECT *
FROM orders
WHERE user_id = 10086;

EXPLAIN ANALYZE
SELECT *
FROM orders
WHERE user_id = 10086;

我会重点看三件事：估算 rows 是否离谱，实际扫描行数是否可接受，Extra 或 trace 里是否出现 skip scan 相关信息。只看到用了索引还不够，真正要看它有没有让延迟分位稳定下来。

用 optimizer_switch 做 A/B

生产排查时，我不会直接改全局开关，而是在测试连接或灰度会话里对比：

SET optimizer_switch='skip_scan=off';
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 10086;

SET optimizer_switch='skip_scan=on';
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 10086;

如果打开 Skip Scan 后 rows 和实际耗时明显下降，而且在高峰流量下 p95/p99 也更稳，那它就是有效路径。如果只是 EXPLAIN 看起来漂亮，实际执行还是抖，就别把它当救命稻草。

什么时候该补专用索引

Skip Scan 适合“已有索引刚好能帮一把”的场景，不适合长期支撑核心查询。如果用户查询订单是高频路径，我更愿意建 (user_id, created_at) 这样的专用索引，让访问路径更确定。

尤其当前导列 distinct 很多时，Skip Scan 要枚举的范围会变多，成本可能迅速变差。你不能只看今天的数据量，还要看业务增长后前导列基数会不会扩张。

上线检查清单

• 确认 MySQL 版本和 optimizer_switch 中 skip_scan 状态。
• 保存 skip_scan on/off 两组 EXPLAIN ANALYZE 结果。
• 观察 rows、filtered、执行时间和线上 p95/p99，不只看是否“用了索引”。
• 前导列基数增长快的表，不要长期依赖 Skip Scan。
• 核心高频查询优先设计专用组合索引。
• 上线后盯慢查询、Handler_read_next 和扫描行数变化。

我的经验结论

Skip Scan 是一个很实用的优化器能力，但它不是索引设计的免死金牌。它能让某些“不满足左前缀”的查询少走弯路，也可能在数据分布变化后突然变得不划算。

我的做法是：发现它、验证它、利用它，但不迷信它。只要这条 SQL 是核心路径，最后还是要回到稳定的索引设计和真实线上指标。