我有一张大约29万行长的table。在备份之前，可能需要<200 mb。当我使用 mysqldump ，备份文件需要约800 mb，当我使用 mysql ，我现在看到它有约43万行，比原来的表多了很多（我正在通过heidisqlui检查）。但如果我对主键的总范围进行查询，它与旧表（~290000）相同。可能出了什么问题？
下面是有关特定表的创建代码。它只是一个变量列表（十进制类型）
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
;编辑：这里是我实际使用的dump和restore命令。我们的数据库有六个表，我已经转储了一个表，所以我在这里转储其余的五个表。
转储表：
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这是我在HeidisqlUI上看到的
2条答案
按热度按时间ozxc1zmp1#
如果你想知道大导出文件：这是正常的。
数据以可读的格式（sql）存储，而表空间上的实际数据则以更有效的数据结构（b+树）存储
关于heidisql向您展示的表统计信息：
对于innodb来说，“行数”统计只是一个近似值。
结果
COUNT(*)提供与原始行匹配的实际行数，对吗？近似值会随着时间的推移而改变，并随着您开始处理数据而变得更好。
用于显示表状态的mysql手册页说明：
行数。一些存储引擎（如myisam）存储精确的计数。对于其他存储引擎，比如innodb，这个值是一个近似值，可能与实际值相差40%到50%。在这种情况下，请使用select count（*）获得准确的计数。
kqlmhetl2#
假设你在甩一个
INT，这是数据库中的4字节数量。通过这些例子，你可以看到
INT可以占用一半到三倍的空间(其他数据类型会导致其他示例。）“280k行”是精确的，在您之前不会更改
INSERT/DELETE排。如前所述，“430k”是一个近似值。在转储和加载之后，实际磁盘空间可能略有增加或减少。这是由许多因素造成的。
我们只能忍受这些不太重要的矛盾。
SHOW TABLE STATUS是查看磁盘空间的另一种方法。我认为“计数器”是整数。有什么理由在这上面保留10位小数位：
将所有这些更改为
INT将每列从10字节缩减到4字节。这将把磁盘利用率降低一半。