b+树叶子节点用双向链表有序连接，支持高效范围查询；非叶子节点仅存键和指针，提升扇出、降低树高；天然有序性优化order by/group by；磁盘预读友好，顺序i/o性能显著优于哈希索引。
叶子节点用双向链表串起来了
B+树所有真实数据都只存在叶子节点，而且这些叶子节点不是散落的，是用双向指针连成一条有序链表。这意味着：一旦通过树查找定位到范围起点（比如 age = 18 对应的叶子节点），后续遍历就完全不用再回溯父节点或重新查找——直接顺着链表往后读就行。
常见错误现象是误以为“查到了起始值就完事了”，结果发现 WHERE age BETWEEN 18 AND 30 还是慢。问题往往出在：索引列没建对（比如用了 name 而非 age），或者该列存在大量 NULL 值导致叶子节点实际不连续。
非叶子节点只存键，不存数据，更“瘦”也更“密”
对比 B 树，B+树的非叶子节点只保留索引键和子节点指针，不存任何行数据。这带来两个实际好处：
- 每个节点能塞进更多键，扇出（fan-out）更大 → 同样数据量下树更矮，
SELECT COUNT(*)这类全索引扫描的 I/O 次数更少 - 查询路径更干净：范围扫描时，上层节点纯粹起导航作用，不会干扰叶子层的线性遍历
举个例子：InnoDB 默认页大小 16KB，一个 INT 键占 4 字节，加上指针约 6 字节，单个非叶子节点轻松存下上千个键；而如果像 B 树那样每个节点还要存数据，可能只能存几十个，树高直接翻倍。
排序天然有序，ORDER BY 和 GROUP BY 直接复用
因为叶子节点按索引键严格升序排列并链式连接，只要查询条件能命中该索引，ORDER BY indexed_column 就不需要额外排序（Using filesort 消失）。同理，GROUP BY indexed_column 也能利用链表顺序做流式分组。
容易踩的坑：
- 联合索引中，只有最左前缀匹配且范围条件在末尾时，才能保证后续字段的有序性（例如
(a, b, c)上执行WHERE a = 1 AND b > 2 ORDER BY c可用，但WHERE a > 1 ORDER BY b不行） -
DESC方向需显式建降序索引（MySQL 8.0+ 支持），否则仍会触发文件排序
磁盘预读友好，顺序读比随机读快一个数量级
现代 SSD 或 HDD 都有预读机制：读一个页时，控制器会顺带把后面几个页也拉进内存缓存。B+树叶子链表的物理存储尽量连续（InnoDB 会尝试聚簇），使得范围查询时的磁盘访问模式高度契合预读逻辑——一次 I/O 带来的数据，很可能就是接下来几轮循环要处理的内容。
反例是哈希索引：WHERE id IN (1,2,3,4,5) 看似范围小，但哈希后地址完全离散，五次查询可能触发五次随机 I/O，性能反而不如 B+树一次顺序扫。
真正容易被忽略的一点：即使你只查 SELECT id FROM t WHERE id BETWEEN 1000 AND 1010，如果这 11 行数据在磁盘上跨了 3 个页，B+树仍只需读这 3 个页；但若建的是哈希索引，就得做 11 次独立寻址——这个代价在千万级表里会被放大得非常残酷。
