gpt4 book ai didi

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

转载 作者:可可西里 更新时间:2023-11-01 08:23:38 26 4
gpt4 key购买 nike

我有一个大约有 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 上看到的 enter image description here

最佳答案

如果您对大导出文件感到疑惑:那是正常的。
数据以人类可读的格式(SQL)存储,而表空间上的实际数据存储在更高效的数据结构(B+Tree)中

关于 HeidiSQL 向您显示的表统计数据:
对于 InnoDB,“行数”统计数据只是一个近似值

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

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

SHOW TABLE STATUS 的 MySQL 手册页状态:

The number of rows. Some storage engines, such as MyISAM, store the exact count. For other storage engines, such as InnoDB, this value is an approximation, and may vary from the actual value by as much as 40 to 50%. In such cases, use SELECT COUNT(*) to obtain an accurate count.

关于mysqldump 创建的行多于主键的实际范围,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/53806224/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com