mysqldump创建的行数多于主键的实际范围
mysqldump创建的行数多于主键的实际范围
提问于 2018-12-17 04:31:40
我有一个大约29万行长的表。在备份之前，它可能花费了<200MB。当我使用mysqldump创建这个表的备份时，备份文件占用了大约800MB，当我使用mysql从备份文件重新加载时，我现在看到它有大约430,000行，远远超过原始表(我正在通过HeidiSQL UI检查)。但是如果我对主键的总范围进行查询，它与旧表相同(~290,000)。可能出了什么问题？
下面是所关注的特定表的创建代码。它只是一个变量列表( 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上看到的内容
回答 1
Stack Overflow用户
发布于 2018-12-17 13:15:32
假设您正在转储一个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个字节。这将使磁盘利用率减半。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/53806224
复制相关文章
相似问题