MySQL B+树索引高度通常为2～4层，因16KB页容量、键值与指针大小限制扇出系数约1000，使千万级数据仅需3层（约2200万行），4层达256亿行远超常规需求，再高则IO浪费且应分库分表。
B+树 索引深度通常卡在 2～4 层，不是设计限制，而是物理页容量、键值大小和实际数据量共同约束下的自然结果——绝大多数业务表根本用不到第 4 层，真到了，说明该分库分表了。
为什么高度 rarely 超过 4？看扇出系数怎么算出来的
InnoDB 默认页大小是 16KB，但真正能放索引记录的空间约 15.36KB（扣除页头、页目录等开销）。非叶节点只存键 + 指针：
- INT 主键（4 字节）+ 6 字节页指针 → 单条记录约 10 字节 → 一页最多存约
1536个键 - BIGINT 主键（8 字节）+ 6 字节指针 → 约 14 字节 → 一页约
1097个键 - 实际中 InnoDB 常取保守值
1000作为扇出系数F
所以理论承载行数是 F^(h−1) × 叶子页行数。叶子页按每行约 1KB 估算（含聚簇数据），则：
- 高度 = 2 → 最多
1000 × 16 ≈ 1.6 万行 - 高度 = 3 →
1000² × 16 ≈ 2200 万行 - 高度 = 4 →
1000³ × 16 ≈ 256 亿行
注意：这个“256 亿”是理论上限。现实中，只要主键或行宽膨胀（比如用 VARCHAR(500) 当主键、加 JSON 字段），高度可能在 2000 万 行就升到 4 —— 不是树“想”长高，是每页能塞的键变少了。
查不到 INDEX_HEIGHT 字段？别硬查，用根页分析法推断
MySQL 没提供直接查某索引当前高度的 SQL 函数或字段。试图从 INFORMATION_SCHEMA.INNODB_SYS_INDEXES 或 SHOW INDEX 里找 height 列，会发现根本不存在。
- 最可行的办法是姜承尧提出的“根页分析法”：先通过
TABLE_ID找到索引 ID，再查INNODB_BUFFER_PAGE中PAGE_NUMBER = 3（InnoDB 根页固定位置）且INDEX_ID匹配的记录 - 然后顺着
page no一层层跟踪子页，直到遇到PAGE_TYPE = 'INDEX'且LEVEL = 0（叶子页）为止，路径长度就是高度 - ⚠️ 注意：
INNODB_BUFFER_PAGE默认关闭，开启后有明显性能损耗，仅限临时诊断；生产环境别常开
高度 = 磁盘 IO 次数，但缓存会让它“看起来”更低
B+树 高度直接对应最坏情况下的磁盘 IO 次数：高度为 3，主键等值查询最多触发 3 次物理读（根 → 中间层 → 叶子）。但这不等于每次查询都真发生 3 次 IO：
- 根页几乎总在 Buffer Pool 里，中间层页如果热点高，也可能常驻内存
- 但叶子层 IO 无法避免——尤其当查询随机、Buffer Pool 不够大时，IO 次数就逼近树高
- 一旦高度升到 4，哪怕只有 10% 查询走全路径，也会明显拖慢 P99 延迟
所以 DBA 看到高度为 4，第一反应不是调优索引，而是检查是否该拆表了——因为此时优化空间已极小，IO 成本是结构性的。
别被“4 层能存 256 亿”骗了，关键在行宽和主键类型
所有理论计算都基于“典型键宽 + 典型行宽”。但真实业务中，这两个变量浮动极大：
- 用
UUID或VARCHAR(36)当主键？单键占 36 字节，加上指针，一页可能只剩200～300个键 → 高度 3 的临界点跌到几百万行 - 表里有多个大字段（如
TEXT、JSON），聚簇索引叶子页实际每页只存2～4行 → 同样数据量，树高直接+1 - 二级索引还额外携带主键副本，进一步挤压非叶节点可用空间
这意味着：同样 1000 万行数据，INT 主键 + 紧凑列的表可能还在高度 3，而 UUID 主键 + 多个大字段的表，早就是高度 4 了。树高从来不是数据量的函数，而是“键宽 × 行宽”的函数。
