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