聚簇索引使主键与数据行物理存储一体，范围查询时可顺序读取磁盘页，大幅减少随机I/O；而非聚簇索引需回表逐个查找，导致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 次数仍取决于页内记录密度和页间链表长度
真正决定主键范围扫描快慢的，从来不是“有没有索引”，而是“数据在磁盘上是不是真的挨得近”。聚簇索引把这个问题从软件层直接下沉到了存储组织层面——这是其他索引类型做不到的硬约束。
