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

Question

这是我的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 数据去了哪里？

谢谢!

二本

Answer 1

Data_free 很难预测。

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

如果表没有PARTITIONed，而且很小，那么它通常为零。如果您删除了很多东西，我怀疑它可能是 16KB( block 大小)的一些小倍数。

未PARTITIONed且大小至少为兆字节，则Data_free 通常恰好为4MB、5MB、6MB 或7MB。这是因为 InnoDB 预期需要更多空间而获得 8MB 的“范围”。

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

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

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

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

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