b+树高度随数据量阶梯式跃升，因页大小（16kb）与键指针长度（如bigint 8b+指针 6b）约束单页约存1170个索引项，三层树支撑约2000万行，超限即升至四层，引发磁盘io从3次骤增至4次，显著拖慢查询。
为什么B+树高度会随数据量增长而跳变
B+树高度不是线性增长，而是阶梯式跃升：当单表行数突破某个临界点（比如2000万→5000万），索引页无法再被现有层级容纳，InnoDB必须新增一层来维持结构平衡。这背后是页大小（innodb_page_size=16384）和键长的硬约束——例如主键为BIGINT(8字节)+指针(6字节)，单页最多存约1170个索引项；三层树理论支撑约2000万行，四层才能覆盖上亿行。
树高+1到底多要命：磁盘IO不是加法，是乘法
每层节点访问都可能触发一次随机磁盘IO（尤其叶子页不在Buffer Pool时）。树高从3跳到4，不只是“多一次IO”，而是让原本缓存友好的查询突然暴露在机械盘毫秒级延迟下。更关键的是：innodb_buffer_pool_size通常只够缓存非叶子节点，叶子页仍需频繁换入换出；SSD虽快，但回表时的二次IO叠加依然显著拖慢SELECT * FROM t WHERE idx_col = ?这类常见查询。
别被EXPLAIN骗了：type=ref不等于树高低
EXPLAIN FORMAT=TREE里看到type=ref或using index，只能说明走了索引，完全不能反映当前树高。真正该盯的是：
- 是否出现
type=ALL或key=NULL——那基本是没走索引，和树高无关 -
rows估算值是否远超实际匹配行数——可能是统计信息过期，ANALYZE TABLE能救急 - 执行计划里有没有
Using filesort或Using temporary——这比树高更伤性能
树高本身不可控，但你能控制它何时跳变
InnoDB不提供直接查树高的SQL，也别信用PAGE_NO反推的野路子。务实做法只有两个：
— 用SELECT COUNT(*) + 键长 + 页大小粗估当前是否逼近临界点（比如2000万行、主键+指针≈14字节 → 三层极限已近）
— 当SHOW INDEX FROM tbl显示索引体积超过5GB，或information_schema.INNODB_SYS_INDEXES中SIZE列持续上涨，就是树高可能已跳变的信号
最易被忽略的一点：树高变化不会报错、不写日志、监控项里也没有明确指标——它就静默地让所有“本该快”的查询慢下来，而且慢得毫无征兆。
