当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL 8.4 索引跳过扫描怎么验收：复合索引缺首列时的适用边界

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

来源：17golang原创 2026-08-10 14:54:18 0浏览收藏

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

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

要点速览

复合索引为 (shop_id, created_at) 时，created_at >= ... 可能触发 Skip Scan。
单表查询、覆盖索引、前缀等值、后续带范围条件是几个核心准入门槛。
计划里的 Using index for skip scan 字段，比“用到了某个索引”的标记辨识度高得多。
线上落地前要对比关闭 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，确认统计信息是不是很久没更新了。

通过 ANALYZE TABLE 和 EXPLAIN 检查 Using index for skip scan 计划提示

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

排查的时候可以在当前连接里临时关闭 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 的适用边界摸得差不多。