B+树非叶子节点不存数据可减少磁盘IO：因页大小固定（如16KB），非叶子节点仅存key和指针，可容纳更多键值、扇出更大、树高更低；千万级数据下B+树仅需3层而B树需4层，少一次IO即省10ms（机械盘）或0.1ms（SSD）。
因为B+树在磁盘IO、范围查询、并发稳定性三件事上，B树根本扛不住。
为什么B+树非叶子节点不存数据能少一次磁盘IO
InnoDB默认页大小是16KB，每次磁盘IO至少读一个完整页。B树的每个节点既要存key又要存data（或data pointer），空间被挤占；B+树非叶子节点只存key和子节点pointer，同样一页能塞进更多key——比如B树一页放300个key，B+树能放450个以上。
扇出变大 → 树高降低 → 查询路径变短。一个千万级表，B+树可能只需3层就能定位到叶子，B树却要4层。对机械盘来说，多一次IO就是多10ms；对SSD也是多0.1ms，积少成多就拖慢整个事务链路。
- 实操中可查
SHOW INDEX FROM table_name配合INFORMATION_SCHEMA.INNODB_SYS_INDEXES估算索引树高 - 建复合索引时，把高频等值字段放前面，本质是在帮B+树更快收敛到目标叶子页
- 别指望“树矮一点”能解决所有慢查——如果
WHERE条件没用上最左前缀，B+树照样退化为全索引扫描
为什么范围查询必须靠B+树叶节点链表
B+树所有数据都在叶子节点，且叶子节点用双向链表串起来；B树的数据散落在任意层级节点里。执行WHERE id BETWEEN 100 AND 200时：
- B+树：找到
id=100所在叶子页 → 沿链表往后顺序读，直到id>200为止，全程顺序IO - B树：得从中序遍历角度反复跳转父子节点，大量随机IO，缓存命中率暴跌
这个差异在ORDER BY created_at LIMIT 20或分页场景下特别明显。MyISAM虽然也用B+树，但它的叶子存的是row number，而InnoDB叶子存的是整行数据（聚簇索引），所以InnoDB的范围扫描还能省掉回表这一步。
为什么B+树插入/删除更稳定，尤其在高并发写入时
B+树分裂只发生在叶子节点，且只需调整相邻叶子的链表指针；B树分裂可能发生在任意层级，要挪动key和data，锁住整条路径上的多个节点。
- InnoDB的行锁实际是加在索引记录上的，B+树叶子节点密集、结构规整，锁粒度更容易控制
- 自增主键能避免B+树叶节点频繁分裂——因为新记录总追加在链表末尾，而不是随机插在中间
- 如果业务强制用UUID做主键，B+树会不断在中间位置分裂，产生大量碎片页，
OPTIMIZE TABLE都救不回来
B+树不是“理论上更优”，而是被磁盘物理特性、InnoDB聚簇索引设计、以及真实OLTP负载反复锤炼出来的结果。它把所有关键操作——点查、范围扫、排序、插入——都压到了同一个稳定路径上，没有例外，也没有侥幸。这点恰恰最容易被忽略：不是B+树多厉害，而是其他结构在这些约束下，早就被淘汰干净了。
