这应该是 MySQL 原理中最底层的部分了，我们存在 MySQL 中的数据，到底在磁盘上长啥样。你可能会说，数据不都存储在聚簇索引中吗？但很遗憾，你并没有回答我的问题。我会再问你，那聚簇索引在磁盘上又长啥样？

就像 Redis 的 RDB 文件，最终落在磁盘上就是一个真真切切的 dump.rdb 文件，而 MySQL 就显得有点迷，我们只知道通过 SQL 去拿数据，并不知道数据最终是以什么方式进行存储的。当然，了解其底层的存储逻辑，并不仅仅是为了满足好奇心这么简单。

其底层的存储方式，会影响到聚簇索引中数据的存储，进而影响到 MySQL 的 DML（Data Manipulation Language） 性能，所以对底层存储逻辑有个清晰的认知，就能够在某些对性能有着极致追求的场景下，帮助我们对 MySQL 进行优化。

表在磁盘上到底长啥样

首先我们先不扯像表空间这类的专业词汇，让我们先来建一张表，从磁盘的结构上来看一下。首先你得找到 MySQL 的数据目录，如果你是用 Docker 启动的话，这个目录大概长下面这样：

/data00/docker/volumes/ef876f70d5f5c95325c2a79689db79cc4d1cecb7d96e98901256bd49ca359287/_data

然后我们新建一个叫 test 的 DB，然后在 _data 的这个目录下就会多一个 test 的目录。然后在 test 数据库下新建了一张 student 的表，在 test 目录下就会多出两个文件，分别是 student.frm 和 student.ibd。

可以发现，最终数据在磁盘上的宏观表现其实很简单，就这么些个文件，什么索引啊、页啊都先忽略不管。

对于后缀为 .frm 文件，里面都有啥？里面包含了每张表的元数据，包括了表的结构定义。而 .ibd 文件里则存放了该表的数据和索引。

我看到有人在博客里把 .ibd 写成了 .idb...虽然 db 看着更顺，但很遗憾并不正确，你把 ibd 的全称 innodb data 记住，就不会把缩写记错了。

上面说的这个以表名命名的 ibd 文件，其实还有一个专业术语叫表空间。

顾名思义可以理解为我这个表专属的空间

认识表空间

如果我上来就直接告诉你，InnoDB 中有个概念叫表空间，你大概率是很难理解的。

像上文描述的这种每张表都有自己单独的数据存储文件的，叫独占表空间；相对应的，InnoDB 还有自己的系统表空间，在系统表空间下，所有表的数据都存储在同一个文件中。

那数据什么时候存储在系统表空间，又什么时候存储在独占表空间呢？

这个可以通过 MySQL 的配置项 innodb_file_per_table 来决定。当该配置项开启时，每张表都会有自己单独的表空间；相反，当该配置项关闭时，表数据将会存储在系统的表空间内。

该配置项是默认开启的，你可以在 MySQL 中通过命令 SHOW VARIABLES LIKE 'innodb_file_per_table' 来查看该变量的状态

其实从 MySQL 将独占表空间作为默认的设置来看，你就应该知道独占表空间的性能肯定是要比系统表空间好的。

因为对于系统表空间来说，通常只有一个文件，所有的表数据都在这一个文件中，如果我们对某张表进行 TRUNCATE 操作，需要将分散在文件中各个地方的数据删除。首先这样做性能就不好，其次 TRUNCATE 操作会在该文件中产生很多空闲的碎片空间，并且并不会减少共享表空间文件 ibdata1 的大小。

不能理解的话，可以想象 Java 里的标记-清理垃圾回收算法，该算法会在清理的时候造成大量的内存碎片，不利于提高后期的内存利用率

而对于独占表空间来说，从始至终一整张表的数据都只存储在一个文件，比起共享表空间谁更容易清理并且还能释放磁盘空间，简直是一目了然。所以，对于独占表空间来说，TRUNCATE 的性能会更好。

除此之外，独占表空间能够提升单张表的最大容量限制，这块可能不是很好理解，为什么独占表空间还有这个功效？在这里你只需要记住这个结论就好了，后文讲到页相关的东西时，我们会具体的论证。

了解了表空间的概念之后，我们就可以继续深入了解数据在表空间内到底是怎么存储的了。

深入表空间文件内部

其实在很早之前我讲 InnoDB的内存架构 时我就讲过，在 InnoDB 中，页是其数据管理的最小单位。所以讲道理我们应该从其最小的部分开始，但是之前已经专门写过一篇文章来讨论页了，所以在这里就不赘述了。

表空间由一堆的**页（Pages）**组成，并且每张页的大小是相等的，页大小默认为 16K，当然这个大小可以调整。

页大小可以通过配置项 innodb_page_size 根据业务的实际情况进行调整，可以选择的大小分别为 4K、8K、16K、32K和64K

一堆页组合在一起，就变成了区（Extents）。

每个区的大小是固定的。当我们设置了不同的 innodb_page_size 时，每个区（Extents）内所包含的页的数量、和对应的固定区大小都不同，具体的情况如下图所示。

当 innodb_page_size 为 4K、8K或者16K时，其对应的区（Extents）大小为1M；当其页大小为32K时，区大小为2M；当页大小为64K时，区大小为4M。

MySQL 5.6的时候其实只支持 4K、8K和16K，至于上面说到的32K和64K，是在 MySQL 5.7.6 之后添加的。

随着页和区大小的变动，每个区内所能容纳的 页数量 也会随之改变。举个例子，当 innodb_page_size 的值为 16K 时，每个区就包含 64 页；当其为 8K 时，每个区包含 128 页；当其为 4K 时，每个区就会包含 256 页。

上面聊过，一页一页的数据组成了区，而一个一个区则组成了段（Segments）。

在逻辑上，InnoDB 的表空间就是由一个一个这样的段（Segment)组成的。随着数据量的持续增长需要申请新的空间时，InnoDB 会先请求32个页，之后便会直接分配一整个区（Extents) 。甚至在某个很大的 Segment 内，还会一次性分配 4 个区。

默认情况下，InnoDB 会给每个索引分配两个段（Segment）。一个用于存储索引中的非叶子结点，另一个用于存储叶子结点。

表空间的分类

上面大概介绍了两种表空间类别，分别是系统表空间、独占表空间。接下来就需要详细的了解一下各个表空间分类的细节了。

系统表空间

当我们开启了innodb_file_per_table 这个配置项（默认就是开启的）之后，系统表空间内就只用于存储 Change Buffer 相关的数据。而当我们将其关闭之后，系统表空间内就会存储表和索引相关的数据。当然，在 MySQL 8.0之前，独占表空间内还包含了 Double Write Buffer（两次写缓冲），但在 MySQL 8.0.20 之后被移了出去，存放在了一个单独的文件中。

默认情况下，系统表空间只会有一个叫 ibdata1 的数据文件，当然，它是允许有多个文件存在的。这所有的属性包括文件名称、文件大小都是通过配置项目 innodb_data_file_path 来制定的，举个例子：

innodb_data_file_path=ibdata1:10M:autoextend

这里指明了系统表空间的文件名为ibdata1 ，初始化大小为10M 。你可发现了，这个 autoextend 是个什么鬼？

刚刚说到，初始大小是 10M ，那么随着 MySQL 的运行，其数据量会慢慢的增长，数据文件必须要申请更多的空间来存储数据。而定义了 autoextend InnoDB 就会帮我们自动对数据文件进行扩容，每次扩容申请 8M 的空间。当然，这个 8M 也是可以配置的，我们可以通过配置项 innodb_autoextend_increment 来配置。

独占表空间

这块其实上面在引入的时候已经介绍的差不多了，这里简单的总结一下就好。当配置项 innodb_file_per_table 开启时（现在是默认开启的），每张表的数据都会存储自己单独的数据文件中。

常规表空间

这个暂时不用了解，知道常规表空间跟系统表空间类似，也是一个共享的存储空间就好。

Undo 表空间

这里主要存储 Undo Logs，有了 Undo Logs 我们就可以在事务出错之后快速的将更改回滚。InnoDB 会默认给 Undo 表空间创建两个数据文件，如果没有特别指定，其文件名默认为 undo_001 和 undo_002 。

至于这两个数据文件的具体存放路径，可以通过配置项 innodb_undo_directory 来指定。当然，如果没有指定，Undo 表空间的数据文件就会放在 InnoDB 的默认数据目录下，通常来说是 /usr/local/mysql 。

而这两个 Undo 表空间数据文件的初始大小，在 MySQL 8.0.23 之前是由 InnoDB 的页大小来决定的，具体的情况如下图：

而在 MySQL 8.0.23 之后，Undo 表空间的初始化大小都是 16M 了。至于 Undo 表空间的扩容，不同的版本也有不通的处理方式。

在 MySQL 8.0.23 之前，每次扩容是申请 4 个区（Extends），按照之前的讨论，如果页大小为 16 K，那么对应到区就是 1M，换句话说，每次扩容申请 4M 的空间，当然这个具体的大小会根据页大小的变化而变化，这个在上文提到过在此就不再赘述。

而在 MySQL 8.0.23 之后，每次最少都要扩容 16 M的空间。而且，为了防止数据量爆发式的增长，InnoDB 对扩容的容量会做一个动态的调整。

如果本次扩容和上次扩容时间差小于 0.1 秒，则扩容的空间会加倍，也就是变成 32 M。如果多次扩容的时间差都小于 0.1 秒，这个 加倍 的操作会 累加，直到达到上限 256M；

那你可能会说，那如果某段时间刚好请求量比较大，使得扩容的容量达到了最大的 256 M，那后续请求量下去了呢？难道还是申请 256 M吗？这显的不太合理。所以 InnoDB 判断如果两次扩容间隔大于 0.1 秒，就会将扩容的容量减半，直到减少到最小限制 16 M。

临时表空间

临时表空间内的数据，顾名思义都是临时的。

你在说屁话...

它分为两个部分，分别是：

• Session 临时表空间
• 全局临时表空间

对于 Session 临时表空间，里面会存储由用户或者优化器创建的临时表。对于每个 Session 来说，InnoDB 最多会分配两个数据文件（表空间），分别用于存储用户创建的临时表和优化器创建的内部临时表。当 Session 失效之后，这些已分配的数据文件会被 Truncate 然后放到一个 数据文件池 中。

这个操作其实跟其他的池化技术没有区别，值得注意的是，这些文件被 Truncate 了之后大小并不会发生变化。而这个数据文件池会在 MySQL 服务器启动的时候创建，里面会默认扔进去 10 个文件，每个文件的默认大小为 5 页。

而对于全局临时表空间，里面会存对临时表做了改动的回滚段（Rollback Segment），其初始化的大小大约是 12 M，同样会在 MySQL 服务器启动的时候创建。

好了以上就是本篇博客的全部内容了，欢迎微信搜索关注【SH的全栈笔记】，回复【队列】获取MQ学习资料，包含基础概念解析和RocketMQ详细的源码解析，持续更新中。

如果你觉得这篇文章对你有帮助，还麻烦点个赞，关个注，分个享，留个言。