MySQL InnoDB Data_Length、Data_free 和 ibd 文件的物理大小答案

【问题标题】：MySQL InnoDB Data_Length, Data_free and physical size of ibd fileMySQL InnoDB Data_Length、Data_free 和 ibd 文件的物理大小
【发布时间】：2015-07-28 12:12:29
【问题描述】：

这是我的 innodb 表的表状态

| Name | Engine | Version | Row_format | Rows   | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time | Check_time | Collation       | Checksum | Create_options | Comment |
+------+--------+---------+------------+--------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------+
| TEST | InnoDB |      10 | Compact    | 172713 |           1175 |   203096064 |       202309632 |            0 |   5242880 |         181935 | 2015-07-21 23:52:24 | NULL        | NULL       | utf8_general_ci |     NULL |                |         |

这是ibd文件的物理大小

213909504 Jul 22 01:35 TEST.ibd

所以 ibd 文件的物理大小和表的 Data_length 之间存在大约 10mb 的差异。我认为 5.2mb 被 mysql 占用为“Data_free”。

我的问题是剩下的 4.8mb 数据到哪里去了？

谢谢！

二本

【问题讨论】：

标签： mysql linux relational-database innodb

【解决方案1】：

Data_free 很难预测。

如果表是使用innodb_file_per_table = 0 创建的，则它是ibdata1 中的可用空间。否则……

如果表不是PARTITIONed，并且它很小，那么它通常为零。如果你删除了很多东西，我怀疑它可能是 16KB（块大小）的小倍数。

不是PARTITIONed 并且至少是兆字节，那么 Data_free 通常正好是 4MB、5MB、6MB 或 7MB。这是因为 InnoDB 在预期需要更多空间时获得了 8MB 的“范围”。

对于 PARTITIONed 表（在 5.7.xx 的“本地分区”之前），每个 PARTITION 看起来、感觉和行为都像一个表。因此，table 的Data_free 实际上是每个分区 4-7MB 的总和。（这是我的经验法则的一个原因，即“除非您期望至少有一百万行，否则不要分区”。）

另一个注意事项：InnoDB 表中有各种“免费”的东西； Data_free 只是冰山一角。它不是很有用。即使使用最新的统计表，我也无法处理每个辅助 INDEX 中的“空闲”空间。

BTrees，当有很多删除/插入时，大约 69% 已满。这 31% 没有暴露在任何类似 Data_free 的指标中。

糟糕我想我没有回答你的问题。首先，5242880 正好是 5*2**20 或 5MB，这是我提到的数字之一。我会猜测另外约 5MB 是另一块未完全测量的可用空间。

.ibd 文件与 ibdata1 文件一样，永远不会缩小。

【讨论】：