背??景最近为了保证线上数据库的稳定性，决定有计划的对一些大表的历史数据进行备份迁移。然而，我发现了一个奇怪的现象。不一致！？0.0Navicat作为数据库管理工具，Navicat在业界非常流行。先不说你电脑上运行的Navicat是正版还是盗版（你不说我就知道）。自开发以来，我尝试了很多类似的工具。Navicat在功能上，尤其是在细节上，已经完全碾压了其他数据库管理工具。我不会在这里列出它们。一句话，非常好用（不接受反驳，除非你说出来一个让我信服的工具）。经过这次大表的迁移备份，我的总体思路是：先用Navicat把库中的所有表按照行数降序排列，然后选择Top10进行迁移备份。但是一如既往，我发现它界面上的统计行数和我的统计表的行数不一致？！你是想颠覆我对Navicat的认知吗？从big_table_name中选择count(1)；为什么？这让我很吃惊。有一阵子我以为自己出现了幻觉。在一次次确认自己没有戴VR眼镜后，我踏上了寻找答案的旅程。开始以为Mysql作为数据库，肯定有每个表的统计信息，而Navicat只是一个可视化界面，让数据肉眼可见。Navicat：我不为此负责。为了证实我的猜想，我查阅了官方文档和其他相关资料。果然MySQL把所有表的信息都存储在了information_schema.TABLES表中。从information_schema.TABLES中选择*；查了这张表，发现表中的统计记录TABLE_ROWS字段与实际计数不符...这是为什么呢？我又陷入了沉思，带着疑惑继续看文件。突然看到MySQL官方文档中对TABLE_ROWS的解释：行数。一些存储引擎，例如MyISAM，存储准确的计数。对于其他存储引擎，例如InnoDB，这个值是一个近似值，可能与实际值相差40%到50%。在这种情况下，请使用SELECTCOUNT(*)来获得准确的计数。看完这段话，我明白了，嗯，你也明白是怎么回事了吗？什么？你不明白吗？嗯，没关系，你可能需要通过直译+对翻译软件的理解来理解真正的意思。原来是TABLE_ROWS字段的计数规则与不同的存储引擎不一致。例如，MyISAM引擎存储TABLE_ROWS中存储的确切行数。对于其他存储引擎，比如InnoDB，这个值只是一个近似值，与实际值相差40%。-50%左右。所以，在这种情况下，我们想要得到一个准确的计数，只能使用SELECTCOUNT(*)来获取。那么如何解决呢？虽然疑惑得到了解答。不过像我这样有强迫症的朋友肯定会问，这个值怎么修正呢？你知道的越多，你不知道的就越多。网上说通过Analyzetablebig_table_name可以修正数据，但是我执行后发现无法修正数据，而且这个操作不仅耗时而且锁表，所以不推荐。。。说到这里，我的强迫症自愈了。朋友，你有更好的方法吗？欢迎留言。请关注微信公众号：程序员小明！！！本文可转载，但必须注明原文出处。程序员小明，一个很少加班的程序员。欢迎关注微信公众号“程序员小明”获取更多优质文章。
