近期为了保障线上数据库的稳定性，我决定针对一些大表的历史数据有计划地进行备份迁移，但是呢，发现一个奇特的现象，Navicat统计行数和表自身count统计数竟然不一致！？0.0
Navicat作为数据库管理工具，在业界广受欢迎，先甭管你电脑上现在正在运行的Navicat是正版还是盗版（你不说我也知道），不可否认的是，在我从事17年从事后端开发以来，尝试了很多同类工具，Navicat在功能上完全碾压其他数据库管理工具，尤其是细节方面，在这里不一一列举了，总之一个字，就是很好用（不接受反驳，除非你说出来一个让我心服口服的工具）。
这次大表迁移备份，我的整体思路是：首先用Navicat对库内所有的表按照行数降序排序，然后选取Top10进行迁移备份。但是一如既往细心的我发现，它界面的统计行数竟然和我自己count这张表行数不一致？！难道要颠覆我对Navicat的认可嘛。
这让我很是诧异，一度以为自己出现了幻觉，再三确认自己没有带VR眼镜后，我踏上了寻找答案的征程。我开始思考，Mysql作为一个数据库，自身肯定就有各个表的统计，而Navicat只是作为一个可视化界面，让数据肉眼可见。
Navicat：这锅我可不背。
为了证实我的猜想，我查阅了官方文档及其他相关资料，果然，MySQL 在 <code>information_schema.TABLES</code>表中息存放了所有表的信息。
查看了这张表以后，发现表里统计记录<code>TABLE_ROWS</code>字段的确实与事实count不符……
我又陷入了沉思，带着疑惑，继续翻阅着文档，突然，看到MySQL官方文档对<code>TABLE_ROWS</code>的解释：
看了这段话我顿悟啦，你是不是也明白怎么回事啦。什么？你没看太明白？好吧，没关系，你可能需要通过翻译软件的直译+理解，才懂得其中真正的含义。原来，<code>TABLE_ROWS</code>这个字段不同存储引擎的计数规则不一致，比如MyISAM引擎这表存储<code>TABLE_ROWS</code>存储的就是精确的行数，而对于其他的存储引擎，比如 InnoDB，这个值只是一个近似值，与实际值相差40%-50%左右。所以，在这种情况下，我们想要得到一个准确的计数，只能使用 SELECT COUNT(*) 来获得。
虽然疑惑得到了解答。但，和我一样有强迫症的朋友肯定会问，如何修正这个值呢？真是知道越多，未知越多，网上说可以通过
得以更正这个数据，但是我动手执行之后发现，并不能更正数据，且该操作不仅耗时还会锁表，并不推荐使用……说到这，我的强迫症竟然不治自愈了。
朋友，你有更好的办法嘛？欢迎留言。
请关注微信公众号：程序员小明！！！
本文可转载，但需声明原文出处。 程序员小明，一个很少加班的程序员。欢迎关注微信公众号“程序员小明”，获取更多优质文章。