我正在将一个数据库从服务器迁移到AWS云端，并决定通过比较旧数据库和新数据库的表的条目数来仔细检查迁移是否成功。
我首先注意到，在我迁移的46张表中，有13张表大小不一，进一步检查后发现，这13张表中居然有9张是 更大 在 较新 的数据库比旧数据库的数据量大。目前在这两个数据库中都没有设置任何脚本code来改变数据，更不用说数据量了。
然后，我进一步检查了旧数据库中的一个较小的表（只有43行），发现在运行下面的sql查询时，我得到的是40个TABLE_ROWS的返回，而不是实际的43行。旧数据库中另一个较小的表也是同样的情况，查询说有8行，但有15行。(我手动统计了多次，确认了这两种情况)
然而，当我在新的、迁移的数据库上运行下面的查询时，就像在旧的数据库上一样，它显示的是这两个表的正确行数。
SELECT TABLE_ROWS, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE.SCHEMA = 'db_name';
有什么想法吗？
阅读文档。https:/dev.mysql.comdocrefman8.0entables-table.html。
TABLE_ROWS 行数。有些存储引擎，比如MyISAM，会存储精确的行数。对于其他存储引擎，比如InnoDB，这个值是一个近似值，可能与实际值相差40%到50%。在这种情况下，使用SELECT COUNT(*)来获得准确的计数。
迁移日志中是否有任何错误警告？迁移mysql表数据的方法有很多，我个人喜欢使用mysqldump和使用mysql命令行客户端导入resuting sql文件。根据我的经验，使用GUI客户端导入总是有一些不足之处。
为了让information_schema在检索大型表的时候不至于痛苦地慢下来，对于InnoDB表，它采用的是估计，基于主键的cardinality。否则，它最终将不得不做 SELECT COUNT(*) FROM table_name对于一个有数十亿行的表来说，这可能需要几个小时。
看看 SHOW INDEX FROM table_name 你会发现，在 information_schema 与PK的基数相同。
运行 ANALYZE TABLE table_name 将会更新统计数据，这可能会使它们更准确，但它仍然是一个估计，而不是及时检查行数。