MYSQL数据库单表建议最大2000万条数据，很多人都说如果超过了2000万条数据，性能就会下降的特别厉害。但是你实际上存储后，发现即使超过了2000万但是查询依旧很快，这是为什么？

Mysql为了查询速度，内部使用了B+树，但是为什么。假设我们有这么一张数据表，其中ID是唯一主键，表内有很多行数据。

        虽然在数据表里它们看起来是挨在一起的，但实际上在存储时，他们被分成了很多小份的数据页，每份大小16K。放到某个页上面，因为行数据被分成了好多份，并且放到了很多个数据页里。为了唯一标识具体是哪一页，我们需要引入页号的信息，同时为了把这些数据页给关联起来，于是引入了前后指针，用于指向前后的数据页，这些字段都被加到了数据页的页头里。

        数据页是需要读写的，为了保证写数据到一半突发意外，还引入了校验码，这个被加入到了页尾中，对于单页的数据查找，Mysql还形成了页目录，页目录可以实现二分查找再次降低时间复杂度，剩下的空间才是用来放行数据的。这样换算下来我们一页中能用于存储数据的内存大概为15K。

        如果想查一条行数据，我们可以把表空间里的每一页都遍历一遍判断里面的行数据是不是我们要找。行数据小的时候这么操作是没什么问题的，行数据大了，性能就慢了，因为每次查找都有可能要遍历所有的行数据，为了加速搜索，我们可以在每个数据页里选出主键ID最小的行数据，而且只需要他们的组件ID以及所在页的页号，将他们组成新的行数据，放入到一个新生成的数据页中，各个新的数据页跟之前的页结构没什么太大的区别，而且大小还是16K，同时为了跟之前的数据页进行区分，新的数据页里需要加入页层级的信息，于是数据页之间就有了上下层级的概念，它其实就是我们常说的B+树。

        我们回去看数据页的结构，大概15K用来存放索引数据，每条索引数据主要有主键和指向页号构成。主键+页号大概12个字节左右，用15K÷12个字节等于1280。

再看叶子节点，叶子节点和非叶子节点的数据结构是一样的，所以也假设掐头去尾剩下15K可以发挥，而叶子节点里放的是真正的行数据。假设一条行数据占1K，那一个数据页里能放15行。

假设B加数是三层，那么计算关系1280的2次方*15，那么数据表的总行数就是二点五千万，这个二点五千万就是单表建议最大行数2000万的由来。单层数据页对应最多3次磁盘IO，时间也在可接受范围内。

但是行数超过一个亿就慢了吗？上面假设单行数据用了1K，所以一个数据页里能放15行数据，如果我单行数据用不了那么多，比如只用了250个字节，那么单个数据页就能放60行数据，那同样是三层B+数，单表支持的行数就能到一个亿。在这里也是三层B+树，在这个B加数里要查找到某行数最多也就是3次磁盘IO，所以并不慢。

在最后看到一位大佬说的

mysql性能下降最根本的原因是内存hold不住高频数据了；树高带来的性能影响忽略不计。
因为mysql的非叶子节点基本都是在内存里面的，叶子节点才会经常被淘汰，如果业务整体高频数据太多了，此时mysql为了腾出内存会频繁触发刷脏，从而影响其它查询走的是磁盘io，这时候效率就很慢了，从这里也可以知道讨论mysql性能要从整体去看，而不是动不动就拿单表数据量说事，阿里巴巴规范固然很好但也不能无脑，分库分表能不用就不用，因为用好的人不多，切记，架构简单是设计原则。

推荐一位优秀的up主：小白debug的个人空间-小白debug个人主页-哔哩哔哩视频 (bilibili.com)