真正生效的唯一信号是type列显示index_skip_scan；Using index for skip scan仅是辅助线索，非决定性依据。
EXPLAIN里没看到Using index for skip scan，是不是没走跳扫？
不是。Using index for skip scan只是辅助线索，真正生效的唯一信号是 type 列显示 index_skip_scan。很多情况下，Extra 里有这串文字，但 type 是 index 或 range，说明实际走的是全索引扫描或普通范围扫描，跳扫根本没触发。
更可靠的方法是：
- 用
EXPLAIN FORMAT=JSON查输出里有没有"skip_scan": true节点 - 看慢查询日志里的
Rows_examined：如果明显低于表总行数（比如 500 万行的表只扫了 12 万），且key显示的是联合索引名，才值得怀疑是跳扫在起作用 - 别信
key字段单独显示了索引名——它只表示“用了这个索引”，不表示“怎么用”
为什么WHERE b = ? 就是不触发index_skip_scan？
跳扫不是语法开关，是优化器基于成本估算后做的选择。常见硬伤包括：
-
ANALYZE TABLE t;没执行过：大批量写入后统计信息过期，优化器误判前导列基数 - 前导列实际唯一值太多：比如
(user_id, created_at)中user_id几乎每行都不同，优化器宁可走主键再回表，也不愿做上百万次“跳跃” - 查询条件含隐式转换：如
status是VARCHAR，但传入数字WHERE status = 1，索引失效，跳扫自然不会启动 - 用了
FORCE INDEX：该提示会绕过跳扫的候选路径评估，哪怕索引结构完全符合也无济于事 - MySQL 版本在 8.0.13–8.0.20 区间：存在多个漏判 bug，升级到 8.0.21+ 更稳定
跳扫真比建单列索引快吗？
不一定。跳扫本质是“对前导列每个 DISTINCT 值，做一次子索引扫描”，I/O 次数 ≈ COUNT(DISTINCT a) × 单次查找成本。这意味着：
- 如果前导列只有 3 个值（如
status），跳扫可能比全表扫描快 5–8 倍 - 但如果前导列有 500 个值，它就要做 500 次 B+ 树定位，随机 I/O 开销可能反超单列索引
- 跳扫无法支持
ORDER BY b或GROUP BY b：它不保证b全局有序，优化器直接弃用 - 覆盖索引场景下（如
SELECT b FROM t WHERE b = ?）跳扫才有优势；否则回表叠加跳跃成本，很可能不如直接建INDEX(b)
如何让跳扫更可控、少踩坑？
跳扫是兜底策略，不是设计原则。真正稳定的解法永远是调整索引结构本身：
- 把高频查询的非首列往前挪：比如常查
city，就把(status, city, create_time)改成(city, status, create_time) - 为高频字段单独建单列索引：简单、跨版本兼容、性能确定，
INDEX(city)比依赖跳扫靠谱得多 - 确认前导列基数是否真低：运行
SELECT COUNT(DISTINCT a) / COUNT(*) FROM t;，比值 - 禁用跳扫调试用：
SET optimizer_switch='skip_scan=off';，对比执行计划变化，能帮你反推优化器的真实决策逻辑
最常被忽略的一点：跳扫只在 WHERE 条件中**完全不出现前导列**时才考虑启用。一旦你写了 WHERE a = ? AND b = ?，优化器就按标准最左前缀走了，跳扫连候选资格都没有。
