MySQL 8.0.13+引入索引跳跃扫描（ISS），本质是将WHERE b=?重写为多个a值的UNION ALL子查询，要求a列唯一值少（如≤20）、无函数/类型转换，且需EXPLAIN FORMAT=TREE验证using_index_skip_scan。
MySQL 8.0 的索引跳跃扫描（Index Skip Scan）不是对 5.7 的“优化”，而是 5.7 根本没有这个功能——它从 MySQL 8.0.13 才首次引入，属于全新能力，不是升级补丁。
为什么 MySQL 5.7 查 b = ? 在 (a, b) 索引上一定走全表扫描？
5.7 完全不识别“跳过最左列”的语义。B+ 树索引按 (a, b) 排序，b 值在物理上是分散的，没有连续区间可定位。优化器只能：要么用索引查 a = ? AND b = ?（最左前缀），要么放弃索引、全表扫。没有任何中间路径。
常见错误现象：EXPLAIN 显示 type: ALL 或 key: NULL，且 Extra 里绝不会出现 Using index for skip scan —— 因为压根不存在这个执行模式。
MySQL 8.0.13+ 怎么让 WHERE b = 5 在 (a, b) 上可能走索引？
它不是“跳过”a，而是把查询逻辑重写为多个带 a 的子查询，再合并结果：
SELECT * FROM t WHERE a = 'val1' AND b = 5 UNION ALL SELECT * FROM t WHERE a = 'val2' AND b = 5 UNION ALL ...
这要求：
-
a列必须是InnoDB表，且COUNT(DISTINCT a)≤ 10～20（比如status、gender） -
WHERE条件里**不能出现a**，也不能含函数、隐式类型转换（如b = '5'而b是INT） - 必须用
EXPLAIN FORMAT=TREE验证，看到index_skip_scan或using_index_skip_scan才算真正启用
8.0 版本间也有关键差异：别踩 8.0.13–8.0.16 的漏触发 bug
早期 8.0 版本（尤其是 8.0.13 到 8.0.16）存在若干 ISS 漏触发问题：即使 a 只有 3 个值、统计信息最新，优化器也可能无视跳扫路径。实测中，ANALYZE TABLE 后仍不生效，大概率是版本缺陷。
建议：
- 生产环境至少使用
8.0.17或更稳定的8.0.25+ - 确认开关状态：
SELECT @@optimizer_switch必须含skip_scan=on（默认开启，但可能被配置覆盖） -
FORCE INDEX和USE INDEX对跳扫无效——它们只控制“用哪个索引”，不控制“怎么用”，跳扫是否发生完全由优化器动态决定
真正容易被忽略的是：ISS 不是性能银弹，而是一个高敏感度的“条件反射”。它依赖精确的基数估算、干净的查询写法、以及恰到好处的数据分布。一旦 a 的 DISTINCT 值从 5 涨到 500，I/O 次数就放大百倍，比全表扫描还慢。别把它当默认选项，先查 COUNT(DISTINCT a)，再决定要不要建单列索引。
