mysqldump恢复后数据丢失

Question

我曾尝试使用mysqldump将一个大约40 on的数据库db1转储到带有innodb默认存储引擎的系统A的sql文件中，并尝试在另一个系统B上恢复它。我已经使用check table status检查了系统A上的任何表损坏，但没有找到任何表损坏。我使用下面的查询计算了系统A和系统B上两个数据库( db1 )上的表大小和每个表的行数，发现系统B的db1上大约有6 6GB的数据丢失。

SELECT table_schema,
    -> SUM(data_length+index_length)/1024/1024 AS total_mb,
    -> SUM(data_length)/1024/1024 AS data_mb,
    -> SUM(index_length)/1024/1024 AS index_mb,
    -> COUNT(*) AS tables,
    -> CURDATE() AS today
    -> FROM information_schema.tables
    -> GROUP BY table_schema
    -> ORDER BY 2 DESC

当Innodb是默认的存储引擎时，我们可以依靠信息模式来计算确切的行数，确切的表大小(datalength + indexlength)吗？为什么在通过系统B进行恢复时，使用mysql转储的转储会导致大量数据丢失？

Answer 1

InnoDB不能给出表中找到的记录的精确计数(使用SELECT COUNT()查询)。当您使用InnoDB引擎请求表上的记录计数时，您将注意到计数将发生变化。

有关详细信息，请参阅InnoDB http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html的MySQL开发人员页面

InnoDB表上的

限制

ANALYZE表通过对每个索引树执行八次随机跳跃并相应地更新索引基数估计来确定索引基数(显示在SHOW index输出的cardinality列中)。由于这些只是估计值，因此重复运行ANALYZE表可能会产生不同的数字。这使得ANALYZE表在InnoDB表上更快，但不是100%准确，因为它没有考虑所有行。

MySQL仅在连接优化中使用索引基数估计。如果某些连接没有以正确的方式进行优化，您可以尝试使用ANALYZE TABLE。在ANALYZE TABLE不能为特定表生成足够好的值的少数情况下，可以在查询中使用FORCE index强制使用特定索引，或设置max_seeks_for_key系统变量以确保MySQL优先使用索引查找而不是表扫描。请参阅第5.1.4节“服务器系统变量”和第C.5.6节“优化器相关问题”。

SHOW table STATUS不提供有关InnoDB表的准确统计信息，但表保留的物理大小除外。行数只是SQL优化中使用的粗略估计。

InnoDB不会在表中保留内部行计数，因为并发事务可能会同时“看到”不同数量的行。为了处理SELECT COUNT(*) FROM t语句，InnoDB将扫描表的索引，如果索引不完全在缓冲池中，这将花费一些时间。如果您的表不经常更改，那么使用MySQL查询缓存是一个很好的解决方案。要获得快速计数，您必须使用您自己创建的计数器表，并让您的应用程序根据插入和删除操作更新它。如果近似行计数足够，则可以使用SHOW TABLE STATUS。请参阅第14.2.12.1节，“InnoDB性能调优技巧”。

Answer 2

检查是否有任何数据丢失的最佳解决方案是比较数据库的内容。

mysqldump --skip-comments --skip-extended-insert -u root -p dbName1 > file1.sql
mysqldump --skip-comments --skip-extended-insert -u root -p dbName2 > file2.sql
diff file1.sql file2.sql

有关详细信息，请参阅this topic。

此解决方案的另一个优点是，您可以看到存在差异的地方。