MYSQL IBD PAGE 页 磁盘占用空间 SQL 的计算方式不可靠

问：MYSQL的一个PAGE 页多大

回答干脆利索，16K呗，我想这是大多数人的第一个反应和回答，这个回答没有毛病。但这16k里面到底有多少是你表中存储的那些实实在在的数据 ？？

这时95%的人肯能已经......

我们都知道,MySql 存储数据的物理单位，不是行，而是数据页，默认是一个16KB的数据单元。实际上 MYSQL的页的大小是可以改变的，可以是8K可以是32K，UNIV_PAGE_SIZE 其实是定义一个MYSQL页面大小的参数，同时UNIV_PAGE_SIZE_SHIFT也是与修改MYSQL 默认页大小有关的量，如果你的页的大小为 16K 则UNIV_PAGE_SIZE_SHIFT的数字必须设置为 14 ，2乘以14次自己，就是16K。（16384）（顺便问一句 MYSQL一行能存储的大小是多少？回味一下）

每个页面中都会分配一个32位的整数页码，通过这个页码，页面之间产生了关系，并且也限制了大小， 232 x 16 KiB = 64 TiB 这就算是一个表最大的存储容量了。所以一个表的大小与单个页面之间的关系如官方下面的图，页面是一个变量的话，其他都不变。

实际上MYSQL 的页面存储的格式也是有分门别类的，在每个数据页的的文件页头中38个字节不是白占用的，他主要负责以下的一些功能

1 监测页面的数据的正确性，FIL_PAGE_CHECKSUM, (还记得MYSQL 广泛提供的页面监测的工具吗) 4 字节

2 FIL_PAGE_OFFSET ，这个其实可以理解为用页面组成的表的每页的编码，用来看看这个物理的文件到底有多少个页面，当前你访问的页面在整体的位置

4个字节

3 FIL_PAGE_PREV FILE_PAGE_NEXT ，我们都在说MYSQL是B+ 树的数据存储结构，其中这两个值就表达了 B + 数据树中的双向链表的形式， 因为他们两个是指针，指定当前页面前一个页面的地址，也指向了当前页面下一个页面的地址。所以每个数据页之间是一个“双向链表”。这对数据的查询时提取数据是非常重要的。

4 FIL_PAGE_LSN 被修改的日志序列位置LSN

5 FIL_PAGE_TYPE 当前页面的类型 页面是B+树叶子节点， UNDO LOG ，索引节点，insert buffer空闲列表，insertbuffer位图， 系统页面，事务系统数据，BLOB页面，文件空间头，扩展描述页 等

6 LSN_FLUSH_LSN 系统表空间的一个页中定义，与普通的数据页面无关

7 FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID 页面数据那个表空间

其中关于当前ibd 文件的中存储的数据的类型可以通过mysql 自带的工具

innochecksum 来进行查看，这里我们打开MYSQL 中的一个ibd文件

在一个MYSQL Per = 1 情况下的页面，我看可以看到这个文件中 有 1337个索引的页面，我们的索引节点 INODE PAGE 只有一个，还有452个新分配的页面，一个insert buffer bitmap 页面， 1个文件 file spave header

我们将这些数字加在一起，1792 * 16384/1024/1024 = 28MB

从实际当中表的ibd文件，我们也可以验证。

所以文件的存储空间与我们的从Ibd文件中导出的数据记录页面的信息的组合最终得出的数据存储页面大小是一致的。

现在马上就有一个疑问

问：那这28MB 的数据空间里面有没有还可以写入数据的页面。

SELECT round((data_length+index_length)/1024/1024,2) FROM information_schema.tables WHERE table_schema='employees' AND table_name='dept_emp';

实际当中通过数据库的方式SQL的语句来获得表占用的数据空间，与通过innochecksum 获得空间之间是对不上的。

对比一下，目前通过 innochecksum 获得数据存储空间占用是 20.89 MB

而通过语句来获得是17.09MB

到底哪个更准确

我们对目前的表进行

OPTIMIZE TABLE dept_emp; 让表中的空间进行一次整理

然后我看一下数值到底有什么改变，通过SQL 来计算后结果是 24.55

而我们再次通过innochecksum来对ibd文件进行查询，占用的数据空间在20.77左右。

同时也做了其他的一些表的空间使用，以及free空间的计算，可以证明通过SQL 来获得当前表的ibd的空间使用，与实际的表在LINUX下的使用情况是对不上的。

而通过innochecksum 来获得数据表的使用情况，是比较稳定，并且也是比较准确的。另外OPTIMIZE后会导致通过SQL 来计算表的空间占用浮动较大，而innochecksum 不会受到影响，并能准确返回实际的磁盘空间使用的情况。