innodb主键查询的磁盘io次数等于b+树高度，根节点到叶子节点每跳一层即一次io（缓存未命中时），高度为3时最多3次io，覆盖千万级数据；高度达4则性能明显劣化。
索引深度直接等于主键查询的磁盘IO次数
InnoDB 的主键查询走 B+ 树，每次从根节点往下跳一层，就触发一次磁盘 IO（除非页已在 Buffer Pool 中）。所以 HEIGHT 值就是最坏情况下的物理 IO 次数。根节点通常常驻内存，但中间节点和叶子节点是否命中缓存，取决于 workload 和 Buffer Pool 大小——不能默认“根节点不计 IO”。
- 高度为 2：最多 2 次 IO（根 → 叶子），对应数据量约 20 万行（主键
INT+ 中等行宽） - 高度为 3：最多 3 次 IO，覆盖绝大多数生产表，理论容量约 3000 万行（如主键
BIGINT+ 行宽 400 字节时，临界点可能低至 2200 万） - 高度为 4：需 4 次 IO，性能开始明显劣化；实际中极少出现，除非单表超 40 亿行或主键/行数据异常膨胀
单表数据量上限不是固定数字，而是由行宽和主键类型动态决定
同样 2000 万行，VARCHAR(500) 主键 + JSON 字段的表，B+ 树可能早早就升到高度 4；而 INT 主键 + 紧凑列的表，撑到 5000 万都还在高度 3。关键变量只有两个：innodb_page_size（默认 16384）、以及每页能塞多少索引项或数据行。
- 非叶子节点容量 ≈
floor(16384 * 0.9 / (主键字节数 + 6))（6 是页指针固定开销） - 叶子节点容量 ≈
floor(16384 * 0.9 / (主键字节数 + 所有列总字节数)) - 行越宽、主键越大，单页存得越少，树就越“高胖”，IO 次数上升得越早
别只看行数，用系统表查真实 HEIGHT 才算数
人工估算容易误判，尤其当存在大量删除、页分裂、填充率低时。直接查 INNODB_SYS_INDEXES 最可靠：
SELECT a.HEIGHT FROM information_schema.INNODB_SYS_INDEXES a JOIN information_schema.INNODB_SYS_TABLES b ON a.TABLE_ID = b.TABLE_ID WHERE b.NAME = 'your_db/your_table' AND a.NAME = 'PRIMARY';
注意：b.NAME 格式是 数据库名/表名（斜杠分隔），不是点号；HEIGHT 是整数，值为 3 就代表当前确实是 3 层结构。
- 如果查出来是
3，但查询变慢，问题大概率不在树高，而在 Buffer Pool 不足、索引未覆盖、或锁竞争 - 如果查出来是
4，且数据量不到千万，说明主键或行结构设计严重不合理（比如用 UUID(CHAR(36)）作主键）
2000 万行不一定安全，4 次 IO 的代价比你想的更重
从 3 次 IO 到 4 次 IO，表面只多一次磁盘寻道，但实际影响被低估：SSD 随机读延迟约 0.1ms，4 次就是 0.4ms；而机械盘可能达 10ms × 4 = 40ms —— 这已接近应用层 RTT 下限。更麻烦的是，并发请求下，4 次 IO 的队列等待、Buffer Pool 淘汰压力、页分裂频率都会指数级上升。
- 不要等
HEIGHT变 4 再行动，高度 3 且数据量 > 2500 万时，就要评估归档或拆分 - 监控重点不是“总行数”，而是
INNODB_METRICS中的index_page_reorg_count和buffer_pool_read_requests比值——它暴露了真实 IO 压力
