b+树高度控制在3–4层是因为扇出系数约1000，使千万级数据仅需3层（约2190万行）、4层可达256亿行，远超常规业务需求，再高会浪费i/o且触发分库分表。
为什么B+树高度卡在3–4层，而不是更高？
因为每多一层，存储容量是扇出系数的指数级增长，而磁盘页大小（16KB）和键值/指针尺寸（如INT主键+页指针共约8–14字节）共同把扇出系数F压在约1000左右——再往上堆层高，既没必要，也浪费I/O。
真实场景中，F ≈ 1170（InnoDB典型值），单叶子页存约16行（按1KB/行估算），那么：
- 2层：最多
F × 16 ≈ 18,720行 - 3层：最多
F² × 16 ≈ 2190万行 - 4层：最多
F³ × 16 ≈ 256亿行
绝大多数业务表远不到千万级，更别说百亿；一旦真接近4层上限，DBA早该考虑分库分表了，而不是靠堆高树。
InnoDB里怎么查某张表的B+树实际高度？
MySQL没提供直接SQL查索引高度，但可以通过INFORMATION_SCHEMA.INNODB_SYS_INDEXES和INFORMATION_SCHEMA.INNODB_SYS_TABLES关联，再结合INNODB_BUFFER_PAGE（需开启innodb_buffer_page监控）间接推断——不过最实用的办法是用姜承尧提出的“根页分析法”：
- 用
SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_INDEXES WHERE TABLE_ID = (SELECT TABLE_ID FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME = 'your_db/your_table');拿到索引ID - 查
INNODB_BUFFER_PAGE中该索引ID对应页类型为INDEX且PAGE_NUMBER = 3（InnoDB根页固定在page no=3）的记录 - 从根页开始逐层
SHOW INDEX+SELECT * FROM INNODB_BUFFER_PAGE跟踪子页，数到叶子页为止
注意：INNODB_BUFFER_PAGE在生产环境默认关闭，开启会带来可观性能开销，仅限诊断时临时启用。
为什么不用红黑树或普通BST做磁盘索引？
红黑树虽然内存中插入/查找稳定在O(log n)，但它的扇出固定为2——意味着1亿条记录的树高约27层，每次查询就要27次磁盘I/O，而机械盘单次I/O约10ms，光找数据就得270ms；SSD虽快些，但依然远不如B+树的3–4次I/O（
- 普通BST更危险：数据顺序插入就退化成链表，
O(n)查找完全不可控 - B+树把所有数据沉到叶子层，内部节点只存键+指针，16KB页能塞上千个键，扇出拉满
- 叶子节点用双向链表串联，范围查询（
BETWEEN、ORDER BY）天然友好，BST做不到
高度受哪些参数影响？哪些其实无关紧要？
真正起作用的是页大小、键长、指针长度和填充率；很多开发者误以为innodb_page_size调大就能减层数，其实它只在建表时生效，且16KB已是InnoDB默认最优值——调到64KB反而可能因缓存局部性下降导致性能倒退。
- 关键变量：
innodb_page_size（建表时定死）、主键类型（INT比BIGINT省4字节）、是否含冗余列（二级索引存主键值，会放大键尺寸） - 无关变量：
sort_buffer_size、join_buffer_size、query_cache（已弃用）——它们不参与B+树结构计算 - 容易被忽略的点：唯一索引和非唯一索引在内部节点存储方式一致，但叶子节点是否去重不影响高度；真正吃空间的是“重复键值+主键组合”，不是“是否唯一”这个标记本身
树高不是调参调出来的，是数据量、键宽、页大小三者自然博弈的结果。想靠改配置把4层压成2层？除非你把主键从BIGINT换成TINYINT，且单行数据压缩到百字节内——这在现实业务模型里基本不可行。
