这是我的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数据的其余部分去了哪里？
谢谢！
厄尔本
答案 0 :(得分：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的外观和感觉都像表一样。因此，表的Data_free实际上是每个分区4-7MB的总和。 （这是我的经验法则的一个原因，即“除非你预计至少有一百万行，否则不要进行分区”。）
另一个注意事项：InnoDB表中有各种“免费”的东西; Data_free只是冰山一角。它不是很有用。即使使用最新的统计数据表，我也无法处理每个辅助INDEX中的“免费”空间。
顺便说一下，当有很多删除/插入时，最多可以达到69％。 31％未在任何类似Data_free的指标中公开。
哎呀我想我没有回答你的问题。首先，5242880正好是5 * 2 ** 20或5MB，这是我提到的数字之一。我将猜测另一个~5MB是另一个没有干净测量的可用空间。
.ibd文件与ibdata1文件一样，永远不会缩小。