MySQL十四：单表最大2000W行数据

Posted 2023-04-01 星河之码

尺有所短，寸有所长；不忘初心，方得始终。

请关注公众号：星河之码

在互联网技术圈中有一个说法：MySQL 单表数据量大于 2000 W行，性能会明显下降。网传这个说法最早由百度传出，真假不得而知。但是却成为了行业内一个默认的标准。

单表超过2000W行数据一定会导致性能下降吗？我认为是不一定的，虽然说建议单表不超过2000W，但是我不接受它的建议可不可以？那必然也是可以的。

一、单表最大到底能存多少数据

先来看看下面这张图，了解一下mysql各个类型的大小

我们知道在MySQL是支持主键自增长的，不考虑其他因素的前提下，理论上只有主键没有用完，表中的数据就可以一直增加。从上图可以中可以分析出：

• 主键类型为Int时

  主键32位，数据最大为2^32-1，大约可以存储21亿的数据，远远大约2KW。

• 主键类型为bigint时

  主键64位，数据最大为2^64-1，存储的数据远远大于了常用的计量单位了，磁盘都达不到这个数量级。

• 主键类型为tinyint时

  主键8位，数据最大为255，Id自增超过255就会报错

由此可見：MySQL能够存储的数据在一定程度上受限与主键的类型。但是数据量的大小却跟2000W没啥影响，既然百度大佬推荐单表最大2000W行数据，那肯定不会是空口白话，一定定会有其他影响行数的因素。

二、数据存储的结构

先不要着急，影响数据行数的因素肯定是有的，在此之前，先来看看数据在InnoDB中是怎么存储在磁盘的，又是怎么读取的。

2.1 数据存储的结构

在MySQL中默认的存储引擎是InnoDB，在之前的《存储引擎》中有说过，InnoDB为每个表都生成了两个文件：

• .frm文件：表结构文件
• .ibd文件：数据文件（聚簇索引包含数据与索引），又叫表空间。

我们表中的的数据其实都是存储在磁盘的.ibd文件中，而每次读取整个.ibd文件无疑是非常慢的，所以在《InnoDB数据文件》中又提到，InnoDB将数据划分为若干个页，以页作为磁盘和内存之间交互的基本单位，InnoDB中页的大小一般为 16KB。如下

从上图中可以很清晰的看出，一个.ibd文件文件是由多个数据页组成的，也就是说一个表的数据会被分散存储在多个数据页中。当然数据页也不仅仅只是存储表中的数据，先来回顾一下页的组成

• 页的组成

如图所示，InnoDB数据页由以下七个部分组成，

从也得组成中我们知道，数据页中还存储了除数据之外的东西，比如数据页的前后指针，页号，页目录等，因此虽然一个数据页一共16KB，但是能够用来存储数据的其实是不足16KB的 。

通过页的组成，我们可以大致分析在数据页中一下查找数据的整体过程：

• 记录被分散在不同的数据页中，InnoDB通过页号【表空间的地址偏移量】来标识数据具体在哪一页中。
• 不通的数据页之间使用前后指针进行关联，避免检索消耗，
• 当找到数据在那个数据页之后，InnoDB为避免遍历检索而提供了一个页目录，页目录通过二分查找将查找效率从O(n) 变成O(lgn)，从而快速定位数据的位置。

2.2 索引的结构

既然在.ibd文件中只要知道了页号，就可以快速定位数据行的位置，从而读取到相应的数据。那么问题来了，我咋知道我要找的数据在那个数据页里，咋知道页号是啥？

万事都有解决的方式，要知道页号其实也简单，无非就两种方式：

• 全表扫描：简单粗暴，没那么多花花肠子，干就完事，但是数据量大了，性能就会下降，非长久之计。
• 通过索引找到数据页：重点了解一下这个

在《索引基本原理》中解释了InnoDB索引是基于B+tree实现的，InnoDB在构建B+tree结构时，一般会找出每个数据页中id最小（或者说索引最小， InnoDB主键即聚簇索引）的记录与其对应的页号，将id与页号组成一个新的记录，存储在一个新生成的数据页中，其大小也为16K，为与存储数据的数据页区分，引入了数据页之间的上下层级关系，也就是页层级（page level）。因此我们知道在B+tree中分为两部分：

• 叶子节点：真正存放表中的数据的数据页，page level = 0
• 非叶子节点：存放索引以及索引对应数据所在的页号的数据页

根据这张B+tree的图，我们知道数据页之间是有地址指向的，如果要找一条数据，最多只需要经历三次磁盘IO就可以将数据页都加载到内存中，从而找到数据，完成查询。

三、B+Tree能存储多少数据

要知道一个B+Tree能存储多少数据其实也不难，B+Tree中的叶子节点存放的是数据，而一个数据页只有16K，我们假设：数据页中页目录，页头，页尾加起来总共占用1KB，剩余15KB全部用了存放数据。

如上图：

• 将B+tree的高度定义为N
• 非叶子节点的数据页存储数量为X，也就是有X个数据页的页号
• 叶子节点的数据页存储数据为Y

根据以上定义，B+tree存储的数据总量：M =X ^ (N-1) * Y

前文中我们说到主键类型会影响行数，那么此时我们假设主键类型为bigint类型，占8个字节，而在InnoDB源码中页号（FIL_PAGE_OFFSET）被设置为4字节。则此时非叶子节点能存储的数据量为

X = 15 * 1024 / (8 +4) = 1280

前面已经将目录，页头，页尾作为1KB排除，所以这里是15

基于此：在来做一个假设，假设叶子节点中存储的数据，每条的大小都为1KB，即每个数据页存储15条数据。

Y = 15

现在来看看B+tree的数据量

• 两层B+tree的数据量（N=2）

  M = X ^ (N-1) * Y = 1280 ^ (2-1) * 15 = 19200 条

• 三层B+tree的数据量（N=3）

  M = X ^ (N-1) * Y = 1280 ^ (3-1) * 15 = 24579000条

• 四层B+tree的数据量（N=4）

  M = X ^ (N-1) * Y = 1280 ^ (4-1) * 15 = 计算器都算不清楚了

  可能还没有写到这么多数据，磁盘已经罢工了

从这里的24579000条，我们就知道为啥单表不推荐超过2000W了，三层B+tree的时候最多只有三次磁盘IO，四层的时候数据量太大，磁盘可能都造不住了。

四、啥时候能超过2000W的数据

不知道大家有没有注意到一点，在上面计算中，我们都是做了很多假设，其中就有一条：假设叶子节点中每条数据占用1KB，以此得出一个数据页的数据量Y=15。

在实际中，要是我一行的数据非常小，仅仅只占用了100KB（比如一个中间表，记录的仅仅是ID），此时

• 叶子节点数据页的数据量

  Y = 15 * 1024 / 100 = 153

• 三层B+tree的数据量

  M = X ^ (N-1) * Y = 1280 ^ (3-1) * 153 = 250675200条

同样是三层B+tree，此时却可以存储2.5亿条数据，增长十倍，但是查找同样只需要三次磁盘IO，并不会对性能有太大影响。

这里说的是【叶子节点】数据页的数据行大小影响了最终存储的数据总量，实际上【非叶子节点】的数据页存储数量X的大小变化的时候，也会影响数据总量，但是这种影响一般会在B-tree中体现。

我们知道B-tree跟B+tree最大的区别就是B-tree的非叶子节点中存储的是真实的数据行，而数据页的大小是16KB固定的，因此相同数据下，B-tree需要更多数据页才能存储数据，数据页增多势必会造成非叶子节点的层级变高，造成更多的磁盘IO，导致性能下降。这也是InnoDB使用B+tree作为索引结构，而不用B-tree的原因。

• 总结

  这里总结一下前文中提的问题其他影响行数的因素？现在就很清晰了，除了主键大小和磁盘限制，最重要的就是索引的结构，即B+tree。

MySQL最大建议行数2000w, 靠谱吗？

点击上方关注 “终端研发部”

设为“星标”，和你一起掌握更多数据库知识

来源 | OSCHINA 社区

作者 | 京东科技开发者

原文链接：https://my.oschina.net/u/4090830/blog/5559454

1、背景

作为在后端圈开车的多年老司机，是不是经常听到过，“mysql 单表最好不要超过 2000w”,“单表超过 2000w 就要考虑数据迁移了”，“你这个表数据都马上要到 2000w 了，难怪查询速度慢”

这些名言民语就和 “群里只讨论技术，不开车，开车速度不要超过 120 码，否则自动踢群”，只听过，没试过，哈哈。

下面我们就把车速踩到底，干到 180 码试试…….

2、实验

实验一把看看…
建一张表

1. CREATE TABLE person(

2. id int NOT NULL AUTO_INCREMENT PRIMARY KEY comment '主键',

3. person_id tinyint not null comment '用户id',

4. person_name VARCHAR(200) comment '用户名称',

5. gmt_create datetime comment '创建时间',

6. gmt_modified datetime comment '修改时间'

7. ) comment '人员信息表';

插入一条数据

1. insert into person values(1,1,'user_1', NOW(), now());

利用 mysql 伪列 rownum 设置伪列起始点为 1

1. select (@i:=@i+1) as rownum, person_name from person, (select @i:=100) as init;

2. set @i=1;

运行下面的 sql，连续执行 20 次，就是 2 的 20 次方约等于 100w 的数据；执行 23 次就是 2 的 23 次方约等于 800w , 如此下去即可实现千万测试数据的插入，如果不想翻倍翻倍的增加数据，而是想少量，少量的增加，有个技巧，就是在 SQL 的后面增加 where 条件，如 id > 某一个值去控制增加的数据量即可。

1. insert into person(id, person_id, person_name, gmt_create, gmt_modified)

3. select @i:=@i+1,

5. left(rand()*10,10) as person_id,

7. concat('user_',@i%2048),

9. date_add(gmt_create,interval + @i*cast(rand()*100 as signed) SECOND),

11. date_add(date_add(gmt_modified,interval +@i*cast(rand()*100 as signed) SECOND), interval + cast(rand()*1000000 as signed) SECOND)

13. from person;

此处需要注意的是，也许你在执行到近 800w 或者 1000w 数据的时候，会报错：The total number of locks exceeds the lock table size，这是由于你的临时表内存设置的不够大，只需要扩大一下设置参数即可。

1. SET GLOBAL tmp_table_size =512*1024*1024; （512M）

2. SET global innodb_buffer_pool_size= 1*1024*1024*1024 (1G);

先来看一组测试数据，这组数据是在 mysql8.0 的版本，并且是在我本机上，由于本机还跑着 idea , 浏览器等各种工具，所以并不是机器配置就是用于数据库配置，所以测试数据只限于参考。

看到这组数据似乎好像真的和标题对应，当数据达到 2000w 以后，查询时长急剧上升；难道这就是铁律吗？

那下面我们就来看看这个建议值 2kw 是怎么来的？

3、单表数量限制

首先我们先想想数据库单表行数最大多大？

1. CREATE TABLE person(

2. id int(10) NOT NULL AUTO_INCREMENT PRIMARY KEY comment '主键',

3. person_id tinyint not null comment '用户id',

4. person_name VARCHAR(200) comment '用户名称',

5. gmt_create datetime comment '创建时间',

6. gmt_modified datetime comment '修改时间'

7. ) comment '人员信息表';

看看上面的建表 sql，id 是主键，本身就是唯一的，也就是说主键的大小可以限制表的上限，如果主键声明 int 大小，也就是 32 位，那么支持 2^32-1 ~~21 亿；如果是 bigint，那就是 2^62-1 ？（36893488147419103232），难以想象这个的多大了，一般还没有到这个限制之前，可能数据库已经爆满了！！
有人统计过，如果建表的时候，自增字段选择无符号的 bigint , 那么自增长最大值是 18446744073709551615，按照一秒新增一条记录的速度，大约什么时候能用完？

4、表空间

下面我们再来看看索引的结构，对了，我们下面讲内容都是基于 Innodb 引擎的，大家都知道 Innodb 的索引内部用的是 B+ 树

这张表数据，在硬盘上存储也是类似如此的，它实际是放在一个叫 person.ibd （innodb data）的文件中，也叫做表空间；虽然数据表中，他们看起来是一条连着一条，但是实际上在文件中它被分成很多小份的数据页，而且每一份都是 16K。大概就像下面这样，当然这只是我们抽象出来的，在表空间中还有段、区、组等很多概念，但是我们需要跳出来看。

5、页的数据结构

因为每个页只有 16K 的大小，但是如果数据很多，那一页肯定就放不下这些数据，那数据肯定就会被分到其他的页中，所以为了把这些页关联起来，肯定就会有记录前后页地址，方便找到对应页；同时每页都是唯一的，那就会需要有一个唯一标志来标记页，就是页号；页中会记录数据所以会存在读写操作，读写操作会存在中断或者其他异常导致数据不全等，那就会需要有校验机制，所以里面还有会校验码，而读操作最重要的就是效率问题，如果按照记录一个个进行遍历，那肯定是很费劲的，所以这里面还会为数据生成对应的页目录（Page Directory）; 所以实际页的内部结构像是下面这样的。

从图中可以看出，一个 InnoDB 数据页的存储空间大致被划分成了 7 个部分，有的部分占用的字节数是确定的，有的部分占用的字节数是不确定的。

在页的 7 个组成部分中，我们自己存储的记录会按照我们指定的行格式存储到 User Records 部分。

但是在一开始生成页的时候，其实并没有 User Records 这个部分，每当我们插入一条记录，都会从 Free Space 部分，也就是尚未使用的存储空间中申请一个记录大小的空间划分到 User Records 部分，当 Free Space 部分的空间全部被 User Records 部分替代掉之后，也就意味着这个页使用完了，如果还有新的记录插入的话，就需要去申请新的页了。这个过程的图示如下。

刚刚上面说到了数据的新增的过程。

那下面就来说说，数据的查找过程，假如我们需要查找一条记录，我们可以把表空间中的每一页都加载到内存中，然后对记录挨个判断是不是我们想要的，在数据量小的时候，没啥问题，内存也可以撑；但是现实就是这么残酷，不会给你这个局面；为了解决这问题，mysql 中就有了索引的概念；大家都知道索引能够加快数据的查询，那到底是怎么个回事呢？下面我就来看看。

6、索引的数据结构

在 mysql 中索引的数据结构和刚刚描述的页几乎是一模一样的，而且大小也是 16K, 但是在索引页中记录的是页 (数据页，索引页) 的最小主键 id 和页号，以及在索引页中增加了层级的信息，从 0 开始往上算，所以页与页之间就有了上下层级的概念。

看到这个图之后，是不是有点似曾相似的感觉，是不是像一棵二叉树啊，对，没错！它就是一棵树，只不过我们在这里只是简单画了三个节点，2 层结构的而已，如果数据多了，可能就会扩展到 3 层的树，这个就是我们常说的 B+ 树，最下面那一层的 page level =0, 也就是叶子节点，其余都是非叶子节点。

看上图中，我们是单拿一个节点来看，首先它是一个非叶子节点（索引页），在它的内容区中有 id 和 页号地址两部分，这个 id 是对应页中记录的最小记录 id 值，页号地址是指向对应页的指针；而数据页与此几乎大同小异，区别在于数据页记录的是真实的行数据而不是页地址，而且 id 的也是顺序的。

7、单表建议值

下面我们就以 3 层，2 分叉（实际中是 M 分叉）的图例来说明一下查找一个行数据的过程。

比如说我们需要查找一个 id=6 的行数据，因为在非叶子节点中存放的是页号和该页最小的 id，所以我们从顶层开始对比，首先看页号 10 中的目录，有 [id=1, 页号 = 20],[id=5, 页号 = 30], 说明左侧节点最小 id 为 1，右侧节点最小 id 是 5；6>5, 那按照二分法查找的规则，肯定就往右侧节点继续查找，找到页号 30 的节点后，发现这个节点还有子节点（非叶子节点），那就继续比对，同理，6>5&&6<7, 所以找到了页号 60，找到页号 60 之后，发现此节点为叶子节点（数据节点），于是将此页数据加载至内存进行一一对比，结果找到了 id=6 的数据行。

从上述的过程中发现，我们为了查找 id=6 的数据，总共查询了三个页，如果三个页都在磁盘中（未提前加载至内存），那么最多需要经历三次的磁盘 IO。
需要注意的是，图中的页号只是个示例，实际情况下并不是连续的，在磁盘中存储也不一定是顺序的。

至此，我们大概已经了解了表的数据是怎么个结构了，也大概知道查询数据是个怎么的过程了，这样我们也就能大概估算这样的结构能存放多少数据了。

从上面的图解我们知道 B+ 数的叶子节点才是存在数据的，而非叶子节点是用来存放索引数据的。

所以，同样一个 16K 的页，非叶子节点里的每条数据都指向新的页，而新的页有两种可能

• 如果是叶子节点，那么里面就是一行行的数据

• 如果是非叶子节点的话，那么就会继续指向新的页

假设

• 非叶子节点内指向其他页的数量为 x

• 叶子节点内能容纳的数据行数为 y

• B+ 数的层数为 z

如下图中所示
Total =x^(z-1) *y 也就是说总数会等于 x 的 z-1 次方 与 Y 的乘积。

X =？

在文章的开头已经介绍了页的结构，索引也也不例外，都会有 File Header (38 byte)、Page Header (56 Byte)、Infimum + Supermum（26 byte）、File Trailer（8byte）, 再加上页目录，大概 1k 左右，我们就当做它就是 1K, 那整个页的大小是 16K, 剩下 15k 用于存数据，在索引页中主要记录的是主键与页号，主键我们假设是 Bigint (8 byte), 而页号也是固定的（4Byte）, 那么索引页中的一条数据也就是 12byte; 所以 x=15*1024/12≈1280 行。

Y=？

叶子节点和非叶子节点的结构是一样的，同理，能放数据的空间也是 15k；但是叶子节点中存放的是真正的行数据，这个影响的因素就会多很多，比如，字段的类型，字段的数量；每行数据占用空间越大，页中所放的行数量就会越少；这边我们暂时按一条行数据 1k 来算，那一页就能存下 15 条，Y≈15。

算到这边了，是不是心里已经有谱了啊
根据上述的公式，Total =x^(z-1) y，已知 x=1280,y=15
假设 B+ 树是两层，那就是 Z =2， Total = （1280 ^1 ）15 = 19200
假设 B+ 树是三层，那就是 Z =3， Total = （1280 ^2） *15 = 24576000 （约 2.45kw）

哎呀，妈呀！这不是正好就是文章开头说的最大行数建议值 2000w 嘛！对的，一般 B+ 数的层级最多也就是 3 层，你试想一下，如果是 4 层，除了查询的时候磁盘 IO 次数会增加，而且这个 Total 值会是多少，大概应该是 3 百多亿吧，也不太合理，所以，3 层应该是比较合理的一个值。

到这里难道就完了？

不
我们刚刚在说 Y 的值时候假设的是 1K ，那比如我实际当行的数据占用空间不是 1K , 而是 5K, 那么单个数据页最多只能放下 3 条数据
同样，还是按照 Z=3 的值来计算，那 Total = （1280 ^2） *3 = 4915200 （近 500w）

所以，在保持相同的层级（相似查询性能）的情况下，在行数据大小不同的情况下，其实这个最大建议值也是不同的，而且影响查询性能的还有很多其他因素，比如，数据库版本，服务器配置，sql 的编写等等，MySQL 为了提高性能，会将表的索引装载到内存中。在 InnoDB buffer size 足够的情况下，其能完成全加载进内存，查询不会有问题。但是，当单表数据库到达某个量级的上限时，导致内存无法存储其索引，使得之后的 SQL 查询会产生磁盘 IO，从而导致性能下降，所以增加硬件配置（比如把内存当磁盘使），可能会带来立竿见影的性能提升哈。

8、总结

• Mysql 的表数据是以页的形式存放的，页在磁盘中不一定是连续的。

• 页的空间是 16K, 并不是所有的空间都是用来存放数据的，会有一些固定的信息，如，页头，页尾，页码，校验码等等。

• 在 B+ 树中，叶子节点和非叶子节点的数据结构是一样的，区别在于，叶子节点存放的是实际的行数据，而非叶子节点存放的是主键和页号。

• 索引结构不会影响单表最大行数，2kw 也只是推荐值，超过了这个值可能会导致 B + 树层级更高，影响查询性能。

9、参考

• https://www.jianshu.com/p/cf5d381ef637

• https://www.modb.pro/db/139052

• 《MYSQL 内核：INNODB 存储引擎 卷 1》

写在最后的话

大家看完有什么不懂的可以在下方留言讨论，也可以私信问我一般看到后我都会回复的。最后觉得文章对你有帮助的话记得点个赞哦，点点关注不迷路
@终端研发部
每天都有新鲜的干货分享！

回复 【idea激活】即可获得idea的激活方式
回复 【Java】获取java相关的视频教程和资料
回复 【SpringCloud】获取SpringCloud相关多的学习资料
回复 【python】获取全套0基础Python知识手册
回复 【2020】获取2020java相关面试题教程
回复 【加群】即可加入终端研发部相关的技术交流群
阅读更多
用 Spring 的 BeanUtils 前，建议你先了解这几个坑！

lazy-mock ，一个生成后端模拟数据的懒人工具

在华为鸿蒙 OS 上尝鲜，我的第一个“hello world”，起飞！

字节跳动一面：i++ 是线程安全的吗？

一条 SQL 引发的事故，同事直接被开除！！

太扎心！排查阿里云 ECS 的 CPU 居然达100%

一款vue编写的功能强大的swagger-ui，有点秀（附开源地址）


相信自己，没有做不到的，只有想不到的在这里获得的不仅仅是技术！



点“在看”支持小于哥呀，谢谢啦