索引树高度直接影响查询I/O次数，树高每增1层，最坏情况下单次查询多一次磁盘读取，I/O开销约翻倍；键值过长、页利用率低、数据量增长未重建索引及小页大小均会导致树变高。
索引树高度直接影响查询的I/O次数，是决定查询性能的关键因素之一。B+树索引每增加一层，范围查询或等值查询可能多一次磁盘读取——而磁盘I/O远慢于内存访问，因此控制树高对性能优化至关重要。
索引树高度如何影响查询效率
B+树的查找过程是从根节点逐层向下遍历，直到叶子节点。每次节点访问通常对应一次页（page）读取。若树高为3，最坏情况下需3次I/O；若因数据膨胀导致树高升至4，同等查询就多一次磁盘访问——在高并发或大数据量场景下，这种增幅会显著拖慢响应速度。
- 树高每+1，单次查询I/O开销约翻倍（尤其在未命中缓冲池时）
- 范围查询受树高影响更明显：需遍历叶子节点链表，但路径查找阶段仍依赖树高
- 主键索引和二级索引树高可能不同，需分别评估
哪些因素会导致索引树变高
树高由节点填充率、键长度、页大小及数据总量共同决定，并非单纯看行数多少。
- 键值过长：如用UUID（36字符）作主键，单个索引项占用空间大，每页存的键减少，加速分裂，推高树高
- 页利用率低：频繁更新/删除造成页内碎片，InnoDB默认填充因子约15/16，但业务写入模式差时实际更低
- 数据量增长但未重建索引：长期累积后，即使总行数不变，碎片也可能抬高树高
- 小页大小配置：MySQL默认16KB页，若人为调小（如测试环境设为4KB），树高会明显上升
如何查看与降低索引树高度
可通过系统表或工具获取当前树高，再针对性优化。
- 查树高（MySQL 8.0+）：SELECT INDEX_NAME, TREE_HEIGHT FROM INFORMATION_SCHEMA.INNODB_INDEX_STATS WHERE TABLE_NAME = 'your_table';
- 用SHOW INDEX FROM your_table观察Cardinality和Index_type辅助判断
- 降低树高常用方法：收缩表（OPTIMIZE TABLE 或 ALTER TABLE ... FORCE）、替换长键为自增整型主键、定期归档冷数据
- 新建索引时指定KEY_BLOCK_SIZE（针对压缩表）或调整innodb_page_size（需重启，慎用）
树高不是孤立指标，需结合查询模式、缓冲池命中率、锁竞争等一起分析。在多数OLTP场景中，将B+树维持在3层以内是较理想的性能基线。
