如何查询实际的Mysql DB大小？

Question

我有一个大的SQL表，大约30 GB，我删除了大约一半。 所以information_schema没有保留正确的信息（直到DB优化）。 有没有办法获得实际尺寸？ 使用全表扫描？

Answer 1

使用InnoDB，许多数字都相当模糊。 单行的大小实际上是不可用的。 SHOW TABLE STATUS （以及对information_schema的等效探测）为您提供估算 。 但是这个估计可能会显着偏离 - 有时超过2倍，高或低。

以下是InnoDB表格布局的简要概述。

数据存储在16KB块的BTree中，由PRIMARY KEY排序。 （我不会讨论其他BTree中的二级索引。）

在这样的结构中插入行可以在期望的块中找到空间，或者可能需要块分割。 删除行可能会标记块的一部分空闲，并且可以（很少）将块返回到“自由空间”。

“avg_row_length”计算为磁盘空间减去“空闲”块，然后除以行数。

但这又到了另一个模糊的数字。 通过在BTree中进行一些探测来估计行数，以查看每个块有多少行，然后进行一些计算。

然后行长度是模糊磁盘空间（不考虑每个块中的空白空间）除以模糊行计数。

我曾提到过“Data_free”。 但请注意，插入/删除行时，如果不更改块数，则不会更改Data_free。

TEXT列（存在一些警告，资格和例外）存储在单独的块中。 分配单元有16KB块。 因此，如果您有任何TEXT或BLOB列，则计算变得非常混乱。

但我不是通过......微小的表被分配了几个16KB的块，但是当它们变得“小”时，空间一次分配8MB。 同样，其中一些可以在Data_free中看到; 很多不能。

“免费”空间分为3类：

• 在“Data_free”中可见，但未释放到操作系统。
• 当发生UPDATEs和INSERTs时，块中的可重用空间。
• 不可见的开销。 通过获取每行中每列的长度，计划表格的空间是表格的2-3倍。

对不起，你的数字不精确。

改变主题......你为什么要做大删除？ 如果你有一个滑动时间尺度（想想：新闻）， PARTITIONs非常好。 如果要替换所有数据，则会想到RENAME TABLE技巧。