聊聊Navicat統計的行數竟然和表實際行數不一致的問題
背景
近期為瞭保障線上數據庫的穩定性,我決定針對一些大表的歷史數據有計劃地進行備份遷移,但是呢,發現一個奇特的現象,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
得以更正這個數據,但是我動手執行之後發現,並不能更正數據,且該操作不僅耗時還會鎖表,並不推薦使用……說到這,我的強迫癥竟然不治自愈瞭。
到此這篇關於Navicat統計的行數竟然和表實際行數不一致的文章就介紹到這瞭,更多相關Navicat行數不一致內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!
推薦閱讀:
- MySQL COUNT(*)性能原理詳解
- MySQL中limit對查詢語句性能的影響
- 一次SQL查詢優化原理分析(900W+數據從17s到300ms)
- MySQL 索引和數據表該如何維護
- MySQL系列之七 MySQL存儲引擎