mysqldump 创建的行多于主键的实际范围
mysqldump creates more rows than the actual range of primary key
我有一个 table 大约有 290,000 行长。在备份之前,它可能花费了 <200 MB。当我使用 mysqldump
创建此 table 的备份时,备份文件占用约 800 MB,当我使用 mysql
从备份文件重新加载时,我现在看到它有 ~430,000行,比原来的 table 多得多(我正在通过 HeidiSQL UI 检查)。但是如果我对主键的总范围进行查询,它与旧的 table (~290,000) 相同。可能出了什么问题?
这是所关注的特定 table 的创建代码。它只是一个变量列表(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
;
编辑:这是我使用的实际转储和恢复命令。我们的数据库有六个 table,我已经转储了一个 table,所以在这里我转储剩下的五个 table。
转储 tables :
mysqldump -u root --single-transaction=true --verbose -p [dbname] --ignore-table=[dbname].images > \path\[backupname].sql
恢复 tables(删除原始数据库并启动一个空数据库后):
mysql -u root -p [db name] < \path\[backupname].sql
这是我在 HeidiSQL 上看到的 UI
如果您对大导出文件感到疑惑:那是正常的。
数据以人类可读格式 (SQL) 存储,而 table 空间上的实际数据存储在更高效的数据结构 (B+Tree)
中
关于 HeidiSQL 向您展示的 table 统计数据:
对于 InnoDB,"number of rows" 统计数据只是一个 近似值.
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.
假设您要转储一个 INT
,这是数据库中的一个 4 字节数量。
Value = 1 -- dump contains ...,1,... -- effectively 2 bytes.
value = -1222333444 -- dump contains ...,-1222333444,... -- 12 bytes
通过这些示例,您会发现 INT
在倾倒时可以占用 space 的一半到 space 的 3 倍。 (其他数据类型导致其他示例。)
“280K 行”是准确的,在 INSERT
/DELETE
行之前不会更改。如前所述,“430K”是一个近似值。
实际磁盘space在转储和加载后可能略有增加或减少。这是由很多因素造成的。
我们只能忍受这些不那么重要的矛盾。
SHOW TABLE STATUS
是查看磁盘 space.
的另一种方式
我认为 "counters" 是整数。有没有理由在这上面保留 10 位小数:
RunningCounter` DECIMAL(20,10)
将所有这些更改为 INT
会将每列从 10 个字节缩小到 4 个字节。这将使磁盘利用率减半。
我有一个 table 大约有 290,000 行长。在备份之前,它可能花费了 <200 MB。当我使用 mysqldump
创建此 table 的备份时,备份文件占用约 800 MB,当我使用 mysql
从备份文件重新加载时,我现在看到它有 ~430,000行,比原来的 table 多得多(我正在通过 HeidiSQL UI 检查)。但是如果我对主键的总范围进行查询,它与旧的 table (~290,000) 相同。可能出了什么问题?
这是所关注的特定 table 的创建代码。它只是一个变量列表(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
;
编辑:这是我使用的实际转储和恢复命令。我们的数据库有六个 table,我已经转储了一个 table,所以在这里我转储剩下的五个 table。
转储 tables :
mysqldump -u root --single-transaction=true --verbose -p [dbname] --ignore-table=[dbname].images > \path\[backupname].sql
恢复 tables(删除原始数据库并启动一个空数据库后):
mysql -u root -p [db name] < \path\[backupname].sql
这是我在 HeidiSQL 上看到的 UI
如果您对大导出文件感到疑惑:那是正常的。
数据以人类可读格式 (SQL) 存储,而 table 空间上的实际数据存储在更高效的数据结构 (B+Tree)
关于 HeidiSQL 向您展示的 table 统计数据:
对于 InnoDB,"number of rows" 统计数据只是一个 近似值.
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.
假设您要转储一个 INT
,这是数据库中的一个 4 字节数量。
Value = 1 -- dump contains ...,1,... -- effectively 2 bytes.
value = -1222333444 -- dump contains ...,-1222333444,... -- 12 bytes
通过这些示例,您会发现 INT
在倾倒时可以占用 space 的一半到 space 的 3 倍。 (其他数据类型导致其他示例。)
“280K 行”是准确的,在 INSERT
/DELETE
行之前不会更改。如前所述,“430K”是一个近似值。
实际磁盘space在转储和加载后可能略有增加或减少。这是由很多因素造成的。
我们只能忍受这些不那么重要的矛盾。
SHOW TABLE STATUS
是查看磁盘 space.
我认为 "counters" 是整数。有没有理由在这上面保留 10 位小数:
RunningCounter` DECIMAL(20,10)
将所有这些更改为 INT
会将每列从 10 个字节缩小到 4 个字节。这将使磁盘利用率减半。