这是我的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 数据去了哪里？
谢谢!
二本
最佳答案
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 文件一样，永远不会收缩。
关于MySQL InnoDB Data_Length、Data_free 和 ibd 文件的物理大小，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31573105/