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（块大小）的一些小倍数，如果你删除了很多东西。

不是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文件一样，永远不会缩小。

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

1 个答案: