聚簇索引的范围查询高效，因其叶子节点存储完整行数据且物理存储按主键有序，支持顺序IO；而非聚簇索引需回表且页不连续，导致随机IO。
因为主键索引（聚簇索引）的叶子节点直接存整行数据，且物理存储顺序与主键值严格一致，所以范围查询能连续读取相邻页，避免随机IO。
聚簇索引的B+树叶子节点是「物理连续」的
在InnoDB中，PRIMARY KEY索引就是聚簇索引，它的B+树叶子节点不是指针，而是真实的数据页。这些页在磁盘上按主键升序链接（通过页内next_record和页间page_no），构成一个逻辑上有序、物理上尽量连续的链表。
这意味着执行类似 SELECT * FROM orders WHERE order_id BETWEEN 1000 AND 2000 时，MySQL只需定位到order_id = 1000所在页，然后顺序扫描后续页，直到超过2000——全程是顺序IO，效率极高。
常见错误现象：
- 用非主键字段做范围查询（如
WHERE created_at > '2025-01-01'），但没建对应二级索引 → 全表扫描 - 建了
created_at单列索引，但它是二级索引 → 叶子节点只存created_at和主键值，查完还得回表，且页不连续 → 随机IO放大
为什么非聚簇索引做范围查询容易慢
二级索引（非聚簇索引）的B+树叶子节点只存索引列值 + 对应主键值，不存实际数据。即使created_at本身有序，它的索引页在磁盘上是分散存放的；更关键的是，按created_at查出一批主键后，还得用这些主键去聚簇索引里逐个找数据行——这叫「回表」，本质是N次随机IO。
使用场景差异：
- 覆盖索引可缓解：比如
SELECT created_at, user_id FROM orders WHERE created_at > '2025-01-01'，若(created_at, user_id)是联合索引，就无需回表 - 但只要SELECT里有其他字段（如
amount、status），就一定触发回表，性能瓶颈立刻暴露
主键设计不当会直接破坏范围查询优势
聚簇索引的排序能力完全依赖主键值的写入模式。如果主键是UUID或MD5这类无序值，新插入的数据会随机落到不同页，造成频繁页分裂、数据碎片化，最终让本该连续的范围扫描退化成大量随机读。
参数与实践建议：
- 优先用自增
INT或BIGINT作主键，保证写入局部性 - 业务上有天然递增字段（如
trade_no带时间戳前缀），可考虑组合主键，但需确认其单调性 - 已有UUID主键表想优化范围查询？只能靠二级索引 + 覆盖字段，无法改变聚簇索引本身的物理乱序问题
最常被忽略的一点：聚簇索引的「范围优势」只对主键本身或以主键为前导的联合索引生效；一旦查询条件脱离主键顺序，就等于放弃InnoDB最核心的物理组织红利，后面所有优化都是补救，不是根源解法。
