MySQL Skip Scan 什么时候会被优化器采用

MySQL Skip Scan 不是“缺少最左列条件也一定能走索引”。它只是在特定复合索引和查询形态下，把首列的不同值当作多个小范围的入口，再对后续列做范围扫描。判断重点有两层：先看查询是否满足候选条件，再看优化器是否因为成本选择了它。

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

先看 Skip Scan 解决了哪一种索引缺口

假设有覆盖索引 (tenant_id, created_at, order_id)，查询只返回这三个字段，却只按 created_at 过滤：

-- 只用于说明查询形态：后续列有范围，结果列都在复合索引内
EXPLAIN SELECT tenant_id, created_at, order_id
FROM orders
WHERE created_at >= '2026-10-01'
  AND created_at 

普通的复合索引范围扫描需要从 tenant_id 开始定位；这里首列没有等值条件，直接构造一个连续范围并不自然。Skip Scan 会先跳到每个不同的 tenant_id，再构造“当前租户 + 日期范围”的子范围。租户取值少、日期窗口窄时，这种分段扫描可能比完整索引扫描更划算。

候选条件要同时满足，而不是只看索引顺序

可以按下面的清单排查。第一，查询只涉及一张表；第二，存在包含前缀列、范围列的复合索引；第三，前缀列的条件是常量等值或 IN()，后面必须有范围条件；第四，查询引用的列都包含在索引中；第五，不能带 GROUP BY 或 DISTINCT。没有过滤的首列并不意味着任何后续列条件都能触发 Skip Scan，函数包裹、复杂非合取条件也可能让候选形态失效。

这解释了一个常见误会：索引是 (tenant_id, created_at)，并不代表 WHERE order_id = 10 就能顺便使用 Skip Scan。官方规则要求索引中存在可识别的范围列，且查询形态能拆成按前缀分组的范围访问。

用 EXPLAIN 判断“候选”还是“已采用”

先执行普通计划查看候选和最终访问路径：

-- 先观察优化器实际选择，不要一开始就 FORCE INDEX
EXPLAIN SELECT tenant_id, created_at, order_id
FROM orders
WHERE created_at >= '2026-10-01'
  AND created_at 

possible_keys 中出现索引，只代表它有资格参与比较；key 是实际采用的索引；传统格式的 Extra 出现 Using index for skip scan，才是确认 Skip Scan 的直接信号。MySQL 8.4 中 skip_scan 默认开启，但会话配置仍可能被改过。需要定位优化器为何放弃时，再结合 optimizer trace 的 skip_scan_range 信息分析。

候选但没采用时，先检查成本边界

满足语法条件只是入场券。前缀列的不同值太多时，Skip Scan 要启动大量子范围；日期范围很宽或命中行很多时，完整索引扫描可能更便宜；查询还需要索引外的列时，回表成本也会削弱收益。统计信息过旧时，估算同样可能偏离实际。

落地时建议保留三步：先用真实数据分布执行 EXPLAIN，再用 ANALYZE TABLE orders 更新统计信息，最后比较真实业务窗口下的扫描行数与响应时间。不要为了制造 Using index for skip scan 而强行改索引；如果首列基数很高、范围很宽，重新设计面向查询的索引往往更稳定。

常见问题

为什么 possible_keys 有索引，Extra 却不是 Skip Scan？
因为 possible_keys 只表示候选集合，优化器仍会按基数、扫描次数、回表和其他访问路径的成本做选择。

关闭 skip_scan 会不会让索引失效？
不会，它只关闭这一种访问方法；其他普通 range、ref 或 index 路径仍可能使用同一索引。应在单个会话中对比计划，避免直接改变全局配置。