InnoDB索引必须用B+树而非B树，因B树节点既存键又存行数据，单页容量小、树高大、IO多（1000万行需6~7次），而B+树非叶节点仅存键和页号，树高仅3~4层，且叶子双向链表支持高效范围查询、排序、分页及预读优化。
为什么InnoDB的索引页必须按B+树组织，而不是B树
因为B树的节点既存键又存行数据，导致单页能装的键数量少，树高被迫抬升——查1000万行数据，B树可能要6~7次磁盘IO，而B+树只要3~4次。innodb_page_size默认是16KB，这个物理页大小固定，B+树靠“非叶子节点只存key和page_no”把更多索引项塞进一页，直接压低树高。
B+树叶子节点用双向链表串联，这不只是为了好看
执行SELECT * FROM t WHERE id BETWEEN 1000 AND 2000 ORDER BY id时，B+树只需定位到id=1000所在的叶子页，然后顺着链表往后扫，全程不跳回父节点；B树做不到这点，它得反复上下遍历，每次跨子树都触发新IO。真实业务里ORDER BY、LIMIT、分页、时间范围查询全依赖这个链表结构。
主键索引（聚簇索引）的数据存放位置决定只能用B+树
InnoDB要求整行数据必须物理上存放在B+树的叶子节点里，且按主键顺序排列。这意味着：
- 非叶子节点不能存
row，否则会破坏“叶子节点才存完整记录”的约定 - 辅助索引的叶子节点必须存
secondary_key + pk，为后续回表做准备——这个设计天然适配B+树的“叶子节点可自定义内容”特性 - B树若在中间层存了某条完整记录，那这条记录就同时出现在两个层级，违反ACID中的一致性前提
别被“B树也能做范围查询”误导，关键看IO路径是否连续
很多人看到B树中序遍历也能输出有序结果，就以为它支持范围扫描。但实际执行时：
- B树遍历需不断从父节点跳到子节点，每次跳转都可能触发随机IO
- B+树的链表在叶子层平铺，相邻记录大概率在连续物理页上，预读机制（
innodb_read_ahead_threshold）能一次加载多页 - MySQL的
change buffer只对B+树叶节点生效，B树没这个优化空间
