MySQL无法直接查询B+Tree高度，最实用方法是通过EXPLAIN FORMAT=TREE观察执行计划，结合行数、页大小与键长估算，通常为3～4层；树高稳定，优化重点应是索引是否被正确使用。
怎么查 MySQL 索引的 B+Tree 高度
MySQL 本身不提供直接返回索引树高度的 SQL 函数，INFORMATION_SCHEMA 里也没有现成字段。最可靠的方式是查 INNODB_SYS_INDEXES 表配合 INNODB_SYS_TABLES，再结合 INNODB_SYS_PAGES（需开启 innodb_monitor_enable='innodb_sys_tables,innodb_sys_indexes,innodb_sys_pages'），但实际中更常用、更轻量的方法是看 EXPLAIN FORMAT=TREE 的输出——它会在执行计划里显式标出“rows”估算和“using index”提示，间接反映是否走到了叶子层。
真正能反推树高的实操路径只有一条：用 SHOW INDEX FROM table_name 确认索引存在后，执行 SELECT COUNT(*) FROM table_name 得到总行数，再根据页大小（默认 innodb_page_size=16384）、键长度、指针大小估算分支因子，最后取对数。比如主键是 BIGINT（8 字节）+ 指针（6 字节），一页存约 1000 个键，则千万级数据树高大概为 3～4 层。
- 别信网上“
SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_INDEXES WHERE NAME='idx_xxx'看PAGE_NO就能算高度”——PAGE_NO是物理页号，和逻辑层级无关 -
EXPLAIN FORMAT=JSON里的"rows"是优化器估算值，不是树高；但若"key_length"明显小于定义长度（比如定义了VARCHAR(255)却只用 10 字节），说明前缀索引生效，实际分支因子变小，树高可能更高 - 唯一索引和普通二级索引在结构上无高度差异，但唯一索引因无需回表+严格匹配，常被优化器优先选中，看起来“更快”，容易误判为“树更低”
为什么 B+Tree 高度通常只有 3～4 层
这不是设计出来的“目标”，而是 InnoDB 页大小（默认 16KB）、记录头开销、索引键压缩机制共同作用下的自然结果。每层节点都尽可能填满，导致扇出（fan-out）极高。例如一个 INT 主键（4 字节）+ 6 字节指针，单页可存约 1600 个键；两层就能寻址 256 万行，三层就是 40 亿行——远超绝大多数业务表规模。
- 树高每 +1，I/O 次数就 +1，但因为 InnoDB 缓冲池（
innodb_buffer_pool_size）默认缓存非叶子节点，真实随机读通常只触发 1 次磁盘 I/O（叶子页） - 如果发现某张表
EXPLAIN显示type=ALL或key=NULL，问题几乎从来不是“树太高”，而是没走索引——先检查WHERE条件是否符合最左前缀，或是否存在隐式类型转换（如WHERE user_id='123'对INT字段） -
innodb_page_size调大（如 64KB）理论上能进一步压低树高，但会导致内存碎片加剧、刷脏页压力上升，官方不建议修改
什么情况下树高会异常升高
树高不会“突然长高”，但某些写法会让优化器放弃使用索引，等效于“绕过 B+Tree”，让查询退化成全表扫描——这时你感觉“怎么这么慢”，其实不是树高问题，而是根本没进树。
-
LIKE '%abc'或OR连接多个非前导条件（如WHERE a=1 OR b=2）会导致索引失效，优化器直接选ALL - 对索引字段用函数或计算：
WHERE YEAR(create_time)=2023或WHERE price*1.1 > 100，B+Tree 无法做范围比较，只能扫全表 - 统计信息过期（
ANALYZE TABLE没跑）时，优化器误判索引选择性，可能弃用高效索引而选错执行计划——此时EXPLAIN看起来走了索引，但rows估算严重偏离实际
要不要为降低树高专门优化索引
没必要。B+Tree 高度天然稳定，只要索引设计合理（区分度够、长度适中、覆盖常用查询），3 层和 4 层在实际性能上几乎没有感知差异。真正该盯的是“有没有走索引”“回表次数多不多”“是否需要覆盖索引”。
- 过度压缩索引字段（比如把
VARCHAR(255)改成VARCHAR(32)）可能省几字节，但对树高影响微乎其微；反而容易引发截断风险 - 复合索引字段顺序错误（把低区分度字段放前面）会导致前缀无效，优化器无法利用索引做范围查找，这才是实际性能杀手
- 唯一要注意的边界情况：超大文本字段建前缀索引（如
INDEX(title(100))）时，若业务查询经常要ORDER BY title，而前缀不足以区分排序顺序，InnoDB 可能被迫额外排序（Using filesort），这比树高多一层更伤
树高是个静态指标，而查询性能是动态博弈的结果。盯着高度不如盯着 EXPLAIN 里那几行关键字段，尤其是 key、rows、Extra 三个。
