近期為了保障線上資料庫的穩定性，我決定針對一些大表的曆史資料有計劃地進行備份遷移，但是呢，發現一個奇特的現象，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(*) 來獲得。
雖然疑惑得到了解答。但，和我一樣有強迫症的朋友肯定會問，如何修正這個值呢？真是知道越多，未知越多，網上說可以通過
得以更正這個資料，但是我動手執行之後發現，并不能更正資料，且該操作不僅耗時還會鎖表，并不推薦使用……說到這，我的強迫症竟然不治自愈了。
朋友，你有更好的辦法嘛？歡迎留言。
請關注微信公衆号：程式員小明！！！
本文可轉載，但需聲明原文出處。 程式員小明，一個很少加班的程式員。歡迎關注微信公衆号“程式員小明”，擷取更多優質文章。