大型单表中的MySQL B树高度问题
内容提要
过去建议MySQL表不超过500万行，担心B树高度增加影响性能。实际上，B树是一个非常扁平的结构，大多数不超过4层。对于一个有1400亿行和27.9TB大小的表，B树高度不超过4层，不用担心性能问题。使用BIGINT作为主键，四级B树可以存储600亿行和12TB数据。即使使用UUID作为主键，MySQL的B树深度也不会超过5级，可以存储到3.8万亿行和386TB数据。总之，不用担心B树高度随数据增长而影响性能，合理设计表结构，大表完全可管理。
延伸解读
B树高度增长的实际影响
文章通过计算表明，B树高度增长非常缓慢。对于sysbench表，即使数据量达到1400亿行、27.9TB，B树高度仍不超过4层。这意味着查询时所需的磁盘I/O次数基本稳定，不会因数据量增长而显著增加。因此，传统“单表不超过500万行”的建议可能过于保守，实际性能影响有限。
主键类型对存储容量的影响
使用BIGINT作为主键时，4层B树可存储约600亿行、12TB数据；而使用UUID作为主键，由于键值更大，非叶子节点存储的记录数减少，4层B树仅能存储约9.7亿行，但5层B树可存储3.8万亿行、386TB数据。尽管UUID会降低单层容量，但B树深度最多增加一层，仍能支撑极大表。不过，最佳实践仍建议避免UUID，以节省空间。
复杂表结构下的B树高度
对于包含多个变长字段的复杂表（如SaaS场景），假设每行约974字节，叶子页仅能存储约16行。但即使如此，使用BIGINT主键时，4层B树仍可存储约138亿行、12.8TB数据。这表明，即使表结构较宽，B树高度依然可控，大表管理并非不可行。
大表管理的现实可行性
文章指出，MySQL单表最大支持64TB，而B树高度在10TB以下通常为4层，超过10TB也仅为5层。实际案例中，PolarDB支持大量超过10TB的表，微博单表60亿行、海外类似微信业务单表数百亿行均运行良好。因此，合理设计表结构后，大表完全可管理，无需过度担忧B树高度问题。
Q&A
为什么过去建议MySQL表不超过500万行？
过去的建议是担心B树高度增加会影响性能，但实际上B树结构非常扁平，大多数不超过4层。
B树的高度对MySQL性能有影响吗？
B树的高度不会显著影响性能，合理设计表结构可以管理大表。
使用BIGINT作为主键有什么优势？
使用BIGINT作为主键时，四级B树可以存储600亿行和12TB数据，性能更优。
如果使用UUID作为主键，B树的深度会如何变化？
即使使用UUID作为主键，B树深度也不会超过5级，可以存储到3.8万亿行和386TB数据。
在复杂表结构中，B树的高度会超过多少层？
在复杂表结构中，B树的高度仍可保持在4层以内，适合大数据量。
如何合理设计MySQL表结构以应对大数据量？
合理设计表结构，包括选择合适的主键类型，可以有效管理大表，避免性能问题。
