想要科学的弄懂这个问题，那必须建立在实际的依据上来计算，想要计算出树高，首先得有三个值：
①索引字段值的大小。
②MySQL中B+Tree单个节点的大小。
③MySQL中单个指针的大小。
如何计算索引字段值的大小呢？
这点要依据字段所使用的数据类型来决定。假设此时表的自增ID，创建表时使用的int类型，int类型在计算机中占4Bytes，那此时基于ID字段建立主键索引时，B+Tree每个节点的索引键大小就为4Bytes。
如何得知MySQL中B+树单个节点的大小呢？
对于索引单个节点的容量是多少呢？在MySQL中默认使用引擎的一页大小作为单节点的容量，假设此时表的存储引擎为InnoDB，就可以通过下述这条命令查询：
SHOW GLOBAL STATUS LIKE "Innodb_page_size";
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| Innodb_page_size | 16384 |
+------------------+-------+
复制代码从上述查询结果来看，InnoDB引擎的一页大小为16384Bytes，也就是16KB，此时也就代表着B+Tree的每个节点容量为16KB。
MySQL中的指针是多大呢？
一般来说，操作系统的指针为了方便寻址，一般都与当前的操作系统位数对应，例如32位的系统，指针就是32bit/4Bytes，64位的操作系统指针则为64bit/8Bytes，但由于64bit的指针寻址范围太大，目前的计算机根本用不上这么大的寻址范围，因此在MySQL-InnoDB引擎的源码中，单个指针被缩小到6Bytes大小。
千万级别的索引树高计算
从上述三条可得知：单个索引节点容量为16KB，主键字段值为4B，指针大小为6B，一个完整的索引信息是由主键字段值+指针组成的，也就是4+6=10B，那此时先来计算一下单个节点中可存储多少个索引信息呢？
16KB / 10B 1638个。
那此时来计算一下，对于一颗高度为2的B+树，根节点可存储1638个叶子节点指针，也就代表着B+Tree的第二层有1638个叶子节点，因为叶子节点要存储实际的行数据，假设表中每行数据为1KB，这也就是代表着一个叶子节点中可存储16条行数据，那么一颗高度为2的B+树可存储的索引信息为：1638 * 16 = 26208条数据。
再来算算树高为3的B+树可以存多少呢？因为最下面一排才是叶子节点，此时树高为3，也就代表着中间一排是叶节点，只存储指针并不存储数据，而每个节点可容纳1638个索引键+指针信息，因此计算过程是：1638 * 1638 * 16 = 42928704条。
是不是很令你惊讶？树高为3的B+Tree，竟然可以存储四千多万条数据，也就代表着千万级别的表，走索引查询的情况下，大致只需要发生三次磁盘IO即可获取数据。
当然，上述的这个数据是基于主键为int类型、表的一行数据为1KB来计算的，实际情况中会不一样，因为主键有可能是bigint类型或其他类型，而一行数据也可能不仅仅只有1KB。因此对于一张实际的千万级别表，它的主键索引实际树高有多少，你结合主键的数据类型以及一行数据的大小，也可以计算出来，它同时不会太高。
对实际的千万表索引树高感兴趣的，我提供一个计算公式：索引键大小=索引字段类型所占的空间、一行表数据大小=所有表字段的类型+隐藏字段（20Bytes）所占大小总和，得到这两个值之后，再套入前面的例子中既可得知。
看到这里，对于索引凭啥那么快？为啥能够提升查询性能？相信大家也有了答案，毕竟索引树高才是个位数，发生的磁盘IO次数也那么少，检索数据的速度不快才来了个鬼~
不过B+Tree中的每个索引页中，还会存储页头（页号、指针、伪记录等）、页目录、页尾等信息，大概一共占用128KB左右，因此想要真正的计算出来接近实际情况的索引树高，还需要把这点考虑在内~
1.5.3、前缀索引为何能提升索引性能？
因为前缀索引可以选用一个字段的前N个字符来创建索引，相较于使用完整字段值做为索引键，前缀索引的索引键，显然占用的空间更少，一个索引键越小，代表一个B+Tree节点中可以存储更多的索引键，等价于树高会越小，也就代表磁盘IO更少，检索数据时自然效率更高。
