共计 1476 个字符，预计需要花费 4 分钟才能阅读完成。
背景
近期为了保障线上数据库的稳定性，我决定针对一些大表的历史数据有打算地进行备份迁徙，然而呢，发现一个奇异的景象，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(*) 来取得。
那又如何修改呢？
尽管纳闷失去了解答。但，和我一样有强迫症的敌人必定会问，如何修改这个值呢？真是晓得越多，未知越多，网上说能够通过
Analyze table big_table_name得以更正这个数据，然而我入手执行之后发现，并不能更正数据，且该操作不仅耗时还会锁表，并不举荐应用……说到这，我的强迫症居然不治自愈了。
敌人，你有更好的方法嘛？欢送留言。
请关注微信公众号：程序员小明！！！
本文可转载，但需申明原文出处。程序员小明，一个很少加班的程序员。欢送关注微信公众号“程序员小明”，获取更多优质文章。