Question

我有一张大约有290,000行的表。备份之前，它可能花费了不到200 MB的内存。当我使用mysqldump创建该表的备份时，备份文件大约需要800 MB，而当我使用mysql从备份文件中重新加载时，我现在看到它具有大约430,000行，更多比原始表（我正在通过HeidiSQL UI进行检查）。但是，如果我对主键的总范围进行查询，则它与旧表相同（〜290,000）。可能出了什么问题？

这是所关注的特定表的CREATE代码。这只是（DECIMAL类型的）变量列表

    CREATE TABLE `ciceroout` (
    `runID` INT(11) NOT NULL AUTO_INCREMENT,
    `IterationNum` DECIMAL(20,10) NULL DEFAULT NULL,
    `IterationCount` DECIMAL(20,10) NULL DEFAULT NULL,
    `RunningCounter` DECIMAL(20,10) NULL DEFAULT NULL,
    \* more 100 variables like this *\
    PRIMARY KEY (`runID`)
)
COLLATE='latin1_swedish_ci'
ENGINE=InnoDB
AUTO_INCREMENT=287705
;

编辑：这是我使用的实际转储和还原命令。我们的数据库有六个表，我已经转储了一个表，所以在这里我转储了其余五个表。

转储表：

 mysqldump -u root --single-transaction=true --verbose -p [dbname] --ignore-table=[dbname].images > \path\[backupname].sql

还原表（在删除原始数据库并启动一个空表之后）：

mysql -u root -p [db name] < \path\[backupname].sql

这是我在HeidiSQL UI上看到的内容

Answer 1

如果您对大型导出文件感到疑惑，那就很正常。
数据以人类可读格式（SQL）存储，而表空间上的实际数据以高效得多的数据结构（B + Tree）存储

关于表统计信息，HeidiSQL向您显示：
对于InnoDB，“行数”统计信息只是一个近似值。

COUNT(*)的结果为您提供了与原始行匹配的实际行数，对吧？

随着时间的推移，近似值会发生变化，并且随着您开始处理数据而变得更好。

SHOW TABLE STATUS的MySQL手册页指出：

行数。一些存储引擎（例如MyISAM）存储精确计数。对于其他存储引擎，例如InnoDB，此值为一个近似值，可能与实际值相差40 到50％在这种情况下，请使用SELECT COUNT（*）获得准确的计数。

Answer 2

假设您正在转储INT，这是数据库中的4字节数量。

Value = 1 -- dump contains ...,1,... -- effectively 2 bytes.
value = -1222333444 -- dump contains ...,-1222333444,... -- 12 bytes

在这些示例中，您看到INT在转储时可以占用一半的空间，并且可以占用三倍的空间。（其他数据类型导致其他示例。）

“ 280K行”是准确的，只有在您INSERT / DELETE行之后才可以更改。如前所述，“ 430K”是一个近似值。

在转储和装入后，实际磁盘空间可能会略有增加或减少。这是由于多种因素造成的。

我们只需要忍受这些非常重要的矛盾。

SHOW TABLE STATUS是查看磁盘空间的另一种方法。

我认为“计数器”是整数。是否有某些理由要对此保留10个小数位：

RunningCounter` DECIMAL(20,10)

将所有这些更改为INT会将每列从10字节缩小为4字节。这样会将磁盘利用率降低一半。

mysqldump创建的行多于主键的实际范围

2 个答案: