聚簇索引的叶子节点即整行数据，物理存储顺序与索引键逻辑顺序一致；主键索引在InnoDB中默认为聚簇索引，支持高效范围查询和排序；若主键非自增（如UUID），将导致页分裂、物理碎片化及随机IO，严重削弱性能。
聚簇索引的叶子节点就是数据本身，顺序即物理存储顺序
主键索引在 InnoDB 中是聚簇索引，它的 B+ 树叶子节点直接存放整行数据，而不是指针或地址。这意味着：当你按主键范围扫描（如 WHERE id BETWEEN 100 AND 200），MySQL 只需从索引树定位到第一个 id=100 的叶子页，然后顺着页内双向链表和页间指针连续读取后续页——所有数据天然“挨着存”，一次磁盘预读就能拉回多行。
这和非聚簇索引完全不同：后者叶子节点只存主键值，查完还得回表，在聚簇索引上再跳一次，IO 次数翻倍。
主键不自增时，逻辑顺序与物理顺序严重错位
如果主键是 UUID 或随机字符串，新插入的数据大概率无法落在当前数据页末尾，而是被插入到中间某个页——触发页分裂、数据移动、碎片化。结果是：
- 逻辑上
ORDER BY id是有序的，但物理上数据散落在不同磁盘块，顺序扫描变成大量随机 IO - 同样查
id BETWEEN ...，原本 1 次预读能覆盖的连续页，现在可能要读几十个离散页 -
SELECT * FROM t ORDER BY id LIMIT 1000这类查询性能断崖式下跌，甚至比全表扫描还慢
联合索引作为聚簇索引时，顺序敏感性更隐蔽
当表没有主键，但存在一个 UNIQUE NOT NULL 索引（比如 (order_no, created_at)），InnoDB 会把它当作聚簇索引。此时“逻辑顺序”由这两个字段共同决定：
- 先按
order_no排序，相同order_no再按created_at排序 - 若你常查
WHERE created_at > '2025-01-01'，但order_no分布极散，那这个范围实际跨越大量无关的order_no值，物理上毫无局部性 - 这种情况下，哪怕加了索引，
EXPLAIN显示用了索引，扫描行数仍可能接近全表
ORDER BY 主键能走索引，但 ORDER BY 非主键列不一定
聚簇索引的排序能力只对它定义的键有效。例如：
-
SELECT * FROM user ORDER BY id→ 直接利用聚簇索引的物理顺序，无需额外排序 -
SELECT * FROM user ORDER BY create_time→ 即使create_time有普通索引，也得先按该索引取出主键，再回表、再排序；若没覆盖索引，filesort几乎必然发生 - 特别注意：
ORDER BY id DESC在 MySQL8.0+ 支持反向扫描聚簇索引，但ORDER BY create_time DESC+LIMIT 10仍可能因无合适索引而慢
真正容易被忽略的是：聚簇索引带来的“顺序红利”只对它自己定义的字段组合起效，且依赖写入模式是否维持了物理连续性。一旦主键设计脱离了单调递增或业务访问局部性，所谓“索引加速”就只剩骨架，没了血肉。
