索引跳跃扫描（index skip scan）是mysql 8.0.13+支持的优化机制，允许在复合索引非最左列（如(a,b)索引上仅查b=?）走索引，条件是：where仅含后缀列等值条件、最左列选择性低、优化器估算代价更低且引擎为innodb。
什么是索引跳跃扫描（Index Skip Scan）
MySQL 8.0.13 起原生支持 INDEX SKIP SCAN，它让优化器能在**复合索引的非最左前缀列上走索引查找**，而无需全表扫描或临时表。典型场景是：你有一个 (a, b) 复合索引，但查询条件只用了 b = ? —— 以前只能放弃索引，现在可以“跳过”a，对每个不同的 a 值单独执行一次 b 的范围扫描。
什么条件下会触发 Index Skip Scan
不是所有 WHERE b = ? 都能自动用上跳扫，必须同时满足：
-
WHERE条件中**仅包含复合索引的后缀列**（不能含最左列），且该列上有等值条件 - 复合索引的**最左列（前缀列）选择性较低**（比如只有几个固定值），否则跳扫开销反而比全表扫描大
- 优化器估算跳扫代价更低——可通过
EXPLAIN FORMAT=TREE观察是否出现"using_index_skip_scan" - 表引擎为 InnoDB；MyISAM 不支持
示例：CREATE INDEX idx_ab ON t(a, b);，执行 SELECT * FROM t WHERE b = 5; 可能触发跳扫；但如果 a 有上百万不同值，优化器大概率弃用。
如何确认和强制使用 Index Skip Scan
查是否启用：运行 SELECT @@optimizer_switch;，确认其中包含 skip_scan=on（默认开启）。禁用它只需 SET optimizer_switch='skip_scan=off';。
强制走跳扫（调试/验证用）：SELECT * FROM t USE INDEX (idx_ab) WHERE b = 5;，再配合 EXPLAIN FORMAT=TREE 看执行计划里是否有 index_skip_scan 字样。
注意：FORCE INDEX 不能强制跳扫，它只强制使用某索引，但不控制访问方式；跳扫是否发生仍由优化器决定。
跳扫的性能陷阱和替代方案
跳扫本质是“对前缀列每个 distinct 值，做一次子索引扫描”，所以实际 I/O 次数 ≈ COUNT(DISTINCT a) × 单次 b 查找成本。容易踩坑的地方：
- 前缀列
a的 distinct 值过多（比如时间戳、UUID），跳扫会退化成几十甚至上百次随机 I/O，比全表扫描还慢 - 跳扫无法用于
ORDER BY b或GROUP BY b—— 它不保证b的全局有序性 - 如果业务真要高频查
b，优先建单列索引(b)，跳扫只是兜底手段，不是替代方案
真正需要跳扫的典型场景，其实是低基数维度+高基数事实的组合，比如 (status, create_time) 上查 create_time > '2024-01-01'，而 status 只有 3 个值。
