主键范围查询快是因为InnoDB聚簇索引将数据按主键物理有序存储，WHERE id BETWEEN 100 AND 200可顺序I/O遍历叶子节点；而其他字段无此有序存储，即使有二级索引也需回表+随机I/O，效率更低。
主键聚簇索引天然支持高效范围扫描，但前提是查询条件必须严格匹配主键的有序性 —— 用错字段、加错条件或数据分布不合理，反而会让范围扫描退化成全表扫描。
为什么主键范围查询快，而其他字段不行？
因为 InnoDB 的聚簇索引把整行数据按主键值顺序物理存储在磁盘页中。执行 WHERE id BETWEEN 100 AND 200 时，MySQL 只需定位到 B+ 树中 key=100 的叶子节点，然后顺序遍历后续叶子节点，直到 key > 200 —— 这是连续的磁盘 I/O，无需跳转。
换成 WHERE created_at BETWEEN '2025-01-01' AND '2025-12-31'（且 created_at 没有索引），就只能全表扫描；即使给它建了二级索引，也得先查索引树拿到主键，再回表查数据页 —— 多一次随机 I/O，范围越大越慢。
哪些写法会破坏主键范围扫描的效率？
以下情况会让 MySQL 放弃使用主键索引做范围扫描，转而走全表或临时索引：
-
WHERE id + 1 > 100：对主键列做函数/计算，索引失效 -
WHERE id IN (SELECT id FROM tmp_ids)：子查询结果不确定顺序，优化器常放弃范围扫描 -
WHERE id >= ? ORDER BY name：如果name不在主键里，且没有覆盖索引，排序可能触发 filesort，打断连续读取 -
WHERE id > ? LIMIT 100000, 10：深度分页导致大量偏移，虽然仍走主键索引，但需跳过前 10 万行数据页，I/O 成本高
如何验证是否真正用了主键范围扫描？
别只看 EXPLAIN 的 type 是不是 range，重点看这几项：
-
key字段是否为PRIMARY -
rows是否接近你预期扫描的主键区间长度（比如BETWEEN 1000 AND 2000，rows应该 ≈ 1000） -
Extra里有没有Using index（说明走的是覆盖，更快）或Using where; Using filesort（说明排序没利用主键顺序）
执行 EXPLAIN FORMAT=JSON SELECT * FROM orders WHERE id BETWEEN 5000 AND 5100;，检查 query_block.nested_loop.access_type 和 index_condition 字段，能更清楚看到是否真正利用了 B+ 树的范围导航能力。
真实业务中容易被忽略的细节
主键范围扫描快，但前提是主键本身“适合范围”。比如用雪花 ID 或 UUID 当主键，虽然唯一，但写入是离散的，会导致：
- 新插入数据频繁引起页分裂，B+ 树深度增加
- 范围查询如
id > 'a1b2c3...'在逻辑上连续，物理上却分散在多个不相邻的数据页 - 缓存命中率下降，实际 I/O 次数远高于理论值
所以，如果你的业务大量依赖时间范围或 ID 区间查询，主键最好用自增整型或带时间戳前缀的有序 ID —— 顺序性比“全局唯一”更重要。
