先看一个核心结论：聚簇索引将主键与数据行在物理存储上合为一体，执行范围查询时可顺序读取磁盘页，大幅减少随机I/O；而非聚簇索引则需要回表逐一查找，引发I/O放大，性能显著下降。其根本原因在于聚簇索引的物理布局把顺序性直接固化到了存储层面。
由于聚簇索引把主键值和数据行紧密绑定在一起存储，范围扫描时便能像翻阅书籍一样连续读取磁盘块，自然比跳跃式查找高效得多。
聚簇索引的数据物理布局决定了顺序性
在 InnoDB 中，聚簇索引（主键索引）的 B+Tree 叶子节点直接存放完整的数据行，而非指针。这意味着主键值的有序性直接体现在数据行在磁盘上的近似连续存放——至少在页内及相邻页之间保持高度局部有序。举例来说，当执行 WHERE id BETWEEN 1000 AND 2000 这类主键范围查询时，MySQL 只需定位到起始 id=1000 对应的叶子页，然后沿着页链表顺序向后遍历，直到超出 2000。整个过程为顺序磁盘读取，单次 I/O 即可加载一整页（默认 16KB）数据，效率远超随机查找。这如同书架上的书籍按编号顺序排列，按编号取书只需顺序滑动，无需在架子中四处翻找。
对比非聚簇索引（二级索引）
二级索引的叶子节点只存储主键值和指针，虽然逻辑上有序，但若要获取完整数据行，必须回表——即用每个查到的主键值再去聚簇索引中查找。这意味着每个主键值都可能触发一次独立的磁盘随机访问（尤其是当数据分布散乱时）。随着范围扩大，回表次数增多，I/O 放大现象愈发严重。值得注意的是，即便使用覆盖索引来避免回表，二级索引本身的数据分布也无法保证物理连续性，它仅仅实现了逻辑顺序。
实际影响性能的关键细节
以下几点容易被忽略，却直接决定了范围扫描的效果：
INSERT顺序至关重要：如果主键采用自增BIGINT，且插入基本按序进行，聚簇索引的页分裂少、物理碎片低，范围扫描自然高效；反之，若使用 UUID 作为主键，频繁的页分裂和数据离散会严重削弱聚簇优势。SELECT *在主键范围扫描中天然受益，但若加上ORDER BY create_time DESC且未命中索引，则强制排序，反而抵消掉聚簇带来的 I/O 优势。- 聚簇索引的“连续”是相对的：InnoDB 并不保证跨页绝对物理邻接（受页合并、删除、填充因子等影响），因此当
EXPLAIN显示type: range时，实际 I/O 次数仍取决于页内记录密度及页间链表长度。
归根结底，决定主键范围扫描速度的核心因素，从来不是“有没有索引”，而是“数据在磁盘上是否真正紧密相邻”。聚簇索引将这一问题从软件层面直接下沉到了存储组织层面——这正是其他索引类型无法实现的硬性约束。
