MySQL 8.4 索引跳过扫描怎么验收：复合索引缺首列时的适用边界

线上有一类查询很容易让人先入为主：索引是 (shop_id, created_at)，SQL 却只按 created_at 筛选。通常我们会说“缺少最左列，索引帮不上忙”，但 MySQL 8.4 还有一个例外——优化器可能把不同的 shop_id 拆成多个小范围，逐段扫描 created_at。这个能力叫 Skip Scan，值不值得依赖，不能单看一次耗时就下结论，得核对执行计划、前缀基数，还有查询本身是不是覆盖索引。

Skip Scan 适合“索引前缀取值不多、后续列带范围条件、查询只需要索引列”的场景。先用 EXPLAIN 确认计划里真的出现 Using index for skip scan，再用真实业务数据和会话级开关做对照测试；它不是所有缺最左列查询的通用补丁。

先看一个“索引存在却没写首列”的订单查询

假设订单明细表按店铺和时间建了联合索引，业务需要查最近一天的明细，结果页只展示索引里已经存好的字段：

CREATE TABLE shop_order_item (
  id BIGINT PRIMARY KEY,
  shop_id BIGINT NOT NULL,
  created_at DATETIME NOT NULL,
  order_no VARCHAR(32) NOT NULL,
  amount DECIMAL(12,2) NOT NULL,
  KEY idx_shop_created (shop_id, created_at)
);

SELECT shop_id, created_at
FROM shop_order_item
WHERE created_at >= '2026-08-09 00:00:00'
  AND created_at 

这条 SQL 没有约束 shop_id，但它只读取 shop_id 和 created_at，两列都落在索引结构里。对这种查询形状，优化器可以先跳到每个不同的 shop_id 节点，再在该前缀下扫描符合条件的时间范围，不用把整个联合索引从头到尾全扫一遍。

Skip Scan 真正依赖哪些数据条件

最容易踩的误解是“只要缺第一列就会自动走跳过扫描”。实际上 MySQL 内部会先算成本，判断分段扫描的开销是不是比全索引扫描更低。shop_id 的不同值太多时，逐个前缀构造范围反而开销更大；如果查询需要回表取大量非索引字段，覆盖索引的优势也会直接消失。

复合索引顺序仍然决定搜索路径

Skip Scan 没有改变 B+Tree 本身的排序规则。它利用的是索引里前缀值的有序分布：先定位第一个 shop_id，再构造 shop_id = ? AND created_at >= ? 的扫描范围，处理完这段之后再跳到下一个前缀。前缀的可选值越少，整个过程的成本优势越容易体现。

覆盖列和单表是重要边界

官方要求的适用前提是查询只关联一个表，并且所有涉及的字段都在索引中。示例里如果改成 SELECT order_no, amount，现有索引没法覆盖返回结果，执行计划就可能转向普通全扫或者其他访问路径。涉及 GROUP BY、DISTINCT 的查询，也不能直接套同一套判断逻辑。

用 EXPLAIN 认出它，不要只看 key 字段

先更新测试数据的统计信息，再查看传统格式的执行计划：

ANALYZE TABLE shop_order_item;

EXPLAIN
SELECT shop_id, created_at
FROM shop_order_item
WHERE created_at >= '2026-08-09 00:00:00'
  AND created_at 

重点别盯着 key = idx_shop_created 这一列看，要去 Extra 里找有没有出现 Using index for skip scan。只有这个提示出现，才能说明执行计划真的走了跳过扫描路径。如果只有 Using index，通常只能说明发生了覆盖索引扫描，不能把它当成 Skip Scan 的判断依据。

需要看更细的成本细节时，可以用树形输出格式的执行计划：

EXPLAIN FORMAT=TREE
SELECT shop_id, created_at
FROM shop_order_item
WHERE created_at >= '2026-08-09 00:00:00'
  AND created_at 

不同数据分布下，优化器完全可能选普通索引扫描。这个结果不代表索引失效，先看 SHOW INDEX FROM shop_order_item 返回的 Cardinality，确认统计信息是不是很久没更新了。

用会话级对照确认优化器是否真的受益

排查的时候可以在当前连接里临时关闭 Skip Scan，再执行同一条查询。这样不会改动全局配置，适合压测或者线上只读观察场景：

SET SESSION optimizer_switch = 'skip_scan=off';

EXPLAIN ANALYZE
SELECT shop_id, created_at
FROM shop_order_item
WHERE created_at >= '2026-08-09 00:00:00'
  AND created_at 

记录两次执行的实际扫描行数、循环次数和耗时，之后恢复会话设置或者重连就行。这里不要只对比冷缓存下的第一次运行结果，也不要把开发机小表上的耗时直接套到生产环境。至少准备三组测试数据：前缀值很少、前缀值较多、时间范围很宽，这几组场景就能把 Skip Scan 的适用边界摸得差不多。

什么时候应该补一个更贴近查询的索引

如果查询长期只按时间过滤，返回结果还要读很多业务字段，直接建立 (created_at, shop_id) 或者包含必要返回列的索引，通常比依赖优化器临场跳过前缀要可控得多。新建索引会增加写入开销和存储占用，所以先用慢查询样本确认访问频率，再走灰度发布流程留好回滚方案。

常见误区与上线前检查

把“possible_keys 有索引”当成已使用

possible_keys 只是候选索引集合，真正选了哪条访问路径要看 key 和 Extra。Skip Scan 的专属识别信号是 Using index for skip scan，不是索引名称本身。

用关闭优化器开关代替索引设计

skip_scan=off 只是诊断工具，不建议设成长期全局配置。要是关闭之后执行计划明显变差，说明当前数据集下这个特性确实有收益；要是开不开都慢，问题大概率出在返回行数、时间范围、统计信息或者索引覆盖度上。

只在一份测试数据上验收

前缀基数和时间范围都会改变优化器的成本估算。发布前把 EXPLAIN、SHOW INDEX、代表性测试参数和两种开关状态下的结果存档，后续表数据量级上涨后还要重新复核。

相关问题

Skip Scan 是否等于跳过联合索引第一列？

可以这么理解，但它不是无条件绕过最左匹配规则，而是把前缀的不同值拆成多个子范围，只有满足所有条件且成本更优时才会启用。

为什么同一条 SQL 有时看不到 Using index for skip scan？

常见原因包括统计信息不准、前缀基数变高、返回列不再满足覆盖要求、查询的时间范围太宽，或者查询形状不满足单表和谓词条件。先更新统计信息，再对比两次的执行计划，不要仅凭一次执行结果就贸然改索引。

Skip Scan 能解决所有慢查询吗？

不能。它只优化了一类索引访问路径；涉及大量回表、排序、聚合或者多表连接的场景，还是要单独分析执行计划和实际数据访问量。

把验收结果留成一张小清单

最终可以把下面四项作为变更记录的最低要求：索引列顺序、代表性 SQL 和对应时间范围、EXPLAIN 里记录的访问方式、开启与关闭 skip_scan 的实际耗时和扫描行数。四项结果都符合预期，才值得把这条路径放到生产观察名单里；不然，补一个查询逻辑更匹配的常规索引往往要稳妥得多。