我做了八年SQL開發(fā)和數據庫優(yōu)化帶過不少新人發(fā)現幾乎每個來面試的候選人都會背“count(1)比count()快count(列名)不統計NULL”但一問到“為什么”“什么場景下用哪個”大多數人就卡殼了。尤其最近在排查慢SQL的時候發(fā)現很多線上事故的根源就是count函數用錯了。今天不聊虛的直接把count(1)、count()和count(列名)這三兄弟扒干凈講清楚它們底層怎么執(zhí)行、性能差在哪、實際項目里怎么選順便把我踩過的坑也一并晾出來。1. 三條count語句的本質區(qū)別很多教程喜歡直接甩結論“count(*)最快、count(1)次之、count(列名)最慢”這話說得太粗暴了容易把人帶溝里。要想真正記住區(qū)別得先回到count函數本身的設計邏輯上來。1.1 count(*) 到底統計了什么count()的語義是“統計結果集中所有行的數量”它完全不關心任何一列的數據內容也不管這一行里的字段是不是NULL。數據庫在執(zhí)行count()時會直接讀取索引或者表中記錄的個數逐行累加最后返回總數。這里有個非常關鍵的點count()不會把行的內容取出來做判斷它純粹是在數“行數”。哪怕這一行的所有字段都是NULL只要這一行存在count()就會算進去。所以在InnoDB引擎下count(*)是統計所有物理存在的記錄行數這個數字是最接近“這張表到底有多少條數據”的答案。1.2 count(1) 和 count(*) 的深度對比先說結論count(1)在語義上等于count()統計的行數范圍和結果完全一樣都是包含NULL行的總行數。很多老程序員喜歡用count(1)理由是“1是個常量比要快”這個說法在早期的Oracle和SQL Server里有一定道理但在現代版本的MySQL、PostgreSQL、SQL Server中這個性能差異已經微乎其微幾乎可以忽略不計。我自己實測過一張500萬行的訂單表在MySQL 8.0 InnoDB下分別執(zhí)行count(1)和count()執(zhí)行計劃完全一致走的索引掃描路徑也一樣耗時差距在毫秒級別沒有任何實際意義。所以現在的開發(fā)規(guī)范里我更傾向于統一用count()——因為它的語義最清晰閱讀代碼的人一眼就能明白“這是在統計總行數”而不是“統計常數1的個數”。另外有個細節(jié)count(1)里的“1”并不是什么魔法數字它只是代表“一個非NULL的常量表達式”。數據庫在處理時會為每一行生成一個常量值1并計數本質上還是在數行。它不會去讀取任何列的數據這一點和count(列名)有本質區(qū)別。1.3 count(列名) 的特殊之處count(列名)的語義就和前兩個完全不同了它統計的是“該列中非NULL值的個數”。比如執(zhí)行count(user_name)數據庫會逐行讀取user_name這一列如果發(fā)現值為NULL就跳過不計數只有當該列有值時計數才加1。這就意味著count(列名)的結果可能小于表的總行數。如果某張表的某個字段允許NULL并且實際數據里確實存在NULL那么count(列名)和count(*)的數量一定不一樣。很多新人在這里栽跟頭拿count(列名)當天數用結果業(yè)務報表對不上。再看一個極端例子如果某一列全為NULLcount(該列)返回的就是0而count(*)返回的是表的總行數。這種差異在數據清洗、空值排查時特別有用但如果你沒意識到這個區(qū)別很容易得出完全錯誤的數據結論。2. 存儲引擎和索引如何影響count的性能上面說的是語義區(qū)別下面聊性能。很多同學把count的性能問題歸結于“用count(*)還是count(1)”這其實找錯了方向。真正決定count快慢的是數據庫的存儲引擎和索引利用情況。2.1 MyISAM與InnoDB的count天壤之別老版本的MySQL里MyISAM引擎對count()的優(yōu)化非常激進它會在表的元數據里直接保存當前表的行數執(zhí)行count()時根本不需要掃描數據直接把這個緩存值取出來返回。所以在MyISAM表上哪怕有幾千萬行count(*)也是毫秒級返回。而InnoDB不支持這種“行數緩存”機制原因很復雜簡單說就是InnoDB為了實現事務隔離和MVCC多版本并發(fā)控制同一個表在不同事務里看到的行數可能是不同的所以沒法維護一個全局統一的計數器。這也是為什么InnoDB下count(*)必須實時掃描數據或索引來統計。這也是一個經典面試陷阱問你“為什么MyISAM的count(*)快InnoDB卻慢”答不上來的話會顯得對存儲引擎理解不深。關鍵點就在MVCC這個我下面細說。2.2 為什么InnoDB不能直接緩存行數MVCC的全稱是Multi-Version Concurrency Control即多版本并發(fā)控制。InnoDB在執(zhí)行事務時不同事務的隔離級別下看到的快照數據可能不一樣。比如事務A開啟后事務B插入了一條新記錄并提交事務A再去執(zhí)行count(*)時如果按可重復讀隔離級別A不應該看到B插入的這條數據。如果InnoDB像MyISAM那樣在元數據里緩存一個總行數那么這個行數應該以哪個事務的快照為準A還是B根本沒法統一回答。所以干脆放棄緩存每次count都按照當前事務的快照去掃描數據這樣才能保證事務隔離性的正確。理解了這一點你就明白為什么InnoDB的大表count()那么慢——因為它真的要把符合條件的索引記錄掃一遍才能得出總數。這也是為什么會有人在千萬級大表上執(zhí)行count()后直接卡死把數據庫拖垮的原因。2.3 索引對count性能的決定性影響如果InnoDB表是一張沒有任何二級索引、只有主鍵的表那么執(zhí)行count(*)時InnoDB只能掃描主鍵聚簇索引。主鍵索引的葉子節(jié)點保存的是整行的全部數據掃描起來IO開銷很大速度自然慢。但如果你給表添加了一個或多個二級索引非主鍵索引InnoDB在優(yōu)化器允許的情況下會選擇“最小的索引樹”來掃描。什么是“最小的索引樹”就是索引的鍵值長度最短的那棵B樹。由于二級索引的葉子節(jié)點只保存索引列和主鍵字段不包含其他列的數據占用的空間更小掃描時讀入的頁更少IO開銷更低速度更快。我用一張幾百萬行的表實測過給一個冗余的tinyint字段添加索引以后count(*)的耗時直接從原來的1.2秒降到了不到0.3秒。所以如果你需要頻繁對某張表統計總行數而表中又沒有合適的短索引可以考慮建一個只用于統計的短字段索引這對大表count性能的提升非常明顯。3. 各數據庫廠商下的表現差異以為理解了MySQL就萬事大吉太天真了。count函數在不同數據庫里的底層執(zhí)行方式差異很大生產環(huán)境切換數據庫時這些細微區(qū)別隨時可能踩雷。3.1 MySQL下的實際執(zhí)行計劃分析在MySQL 8.0的環(huán)境下對同一張表分別執(zhí)行三條SQL并查看執(zhí)行計劃EXPLAIN SELECT COUNT(*) FROM order_info; EXPLAIN SELECT COUNT(1) FROM order_info; EXPLAIN SELECT COUNT(pay_time) FROM order_info;實測下來count(*)和count(1)的執(zhí)行計劃完全一致type為indexkey為某個二級索引掃描行數也相同。而count(pay_time)的執(zhí)行計劃同樣是index掃描但掃描時會逐行判斷pay_time是否為NULL如果pay_time列允許NULL且存在NULL值實際返回的行數會小于掃描行數。還有一個常見誤區(qū)很多人以為count()會選中“所有列”參與計算所以會很慢但優(yōu)化器會自動選擇成本最低的索引來做覆蓋掃描并不會真的去逐一讀取每一行所有列的數據。這也是為什么“count()慢”這個說法在現代MySQL里并不準確真正慢的是沒有索引可用的大表全表掃描。3.2 Oracle和SQL Server的特例Oracle中count(*)和count(1)的性能差異同樣是忽略不計的但count(列名)如果要判斷NULLOracle讀取數據塊后還要額外做一次空值判斷代價稍高。更值得關注的是Oracle用了Bitmap索引或者列式存儲時count的方式會發(fā)生根本變化這種場景不建議把MySQL的經驗直接套過來。SQL Server里有個有趣的細節(jié)它的執(zhí)行計劃對count()做了專門的優(yōu)化會直接用最窄的非聚集索引來做流式計數甚至在某些情況下可以通過統計信息預估行數而不需要完全掃描。但如果你的表是堆表沒有聚集索引count(列名)則必須做全表掃描性能和count()差了一個量級。所以說別把“count用哪個”當成一個固定的銀彈問題必須結合當前數據庫的類型、版本、引擎和索引設計來分析。曾經有個項目從MySQL 5.7遷移到PostgreSQL 14原本在MySQL上跑得好好的count(某列)在PG里優(yōu)化器走了不同的索引路徑耗時直接翻了三倍最后是調整了索引結構才把性能追回來。4. 實戰(zhàn)場景與性能優(yōu)化技巧理論講透了下面直接上實戰(zhàn)。畢竟要真正會用count函數就得知道在什么場景下選擇哪一種以及遇到慢SQL時怎么優(yōu)化。4.1 不同業(yè)務場景下count的選擇建議如果你的業(yè)務邏輯是“只要總數不管某個列是否為空”那么無條件用count()這也是所有規(guī)范里優(yōu)先級最高的寫法。比如統計用戶總量、訂單總量、商品總量一律count()語義準確、可讀性強、性能也不差。如果你的業(yè)務邏輯是“統計某個字段有值的人數”比如統計填寫了手機號的用戶數量、統計有支付記錄的有效訂單數那必須用count(指定列)。但這里有一個隱藏風險該列如果有NULL以外的“偽空值”比如空字符串count(列名)是會統計進去的。如果你想要的是“統計非空且非空字符串的值”那得寫成count(列名)配合WHERE過濾或者用sum(case when 列名 is not null and 列名 ! then 1 else 0 end)。還有一種常見場景是“統計去重后的數量”。count(distinct 列名)和普通count(列名)的語義又不同它統計的是該列去重后的非NULL值的個數。注意distinct會把NULL視為一個值但count(distinct 列名)不統計NULL。這里特別容易混淆劃重點記住。4.2 大表count(*)的三種優(yōu)化策略幾百萬行的小表count(*)無所謂但如果表到了幾千萬甚至上億行每次實時掃描索引都是沉重的負擔。我總結了三類可行的大表count優(yōu)化方案第一類是“定時快照近似值”。比如運營后臺的Dashboard里展示的“總用戶數”真的不需要每一秒都精確到最新值完全可以每十分鐘統計一次把結果寫入一張統計表前端直接查統計表。這樣既保證了展示速度又不會在大表上頻繁跑count。第二類是“匯總表觸發(fā)器或事件”。每次插入、刪除數據時使用事務同步維護一張計數表把count的開銷平攤到每一次DML操作上。適合寫入頻率不高、但查詢頻率極高的表。比如訂單狀態(tài)表寫入量不大就可以用觸發(fā)器維護一個訂單總數計數器。第三類是“利用信息庫表或近似估算”。在MySQL中通過information_schema.tables里的table_rows字段來估算行數這個值不是精確值但很多場景夠用了。注意這個數值在InnoDB里是抽樣估算的誤差可能達到百分之十幾用于幾十億數據規(guī)模的粗略趨勢展示可以但用于對賬、報表精確統計則完全不行。4.3 count(1)和count(*)在慢SQL優(yōu)化中的實戰(zhàn)生產環(huán)境里最常見的慢SQL之一就是頻繁對大表執(zhí)行count()。我自己處理過一個真實案例一張日志表的count()查詢在高峰期竟然需要2秒以上導致接口超時。我當時的排查步驟是第一步用explain查看執(zhí)行計劃發(fā)現走了全表掃描第二步查看表結構發(fā)現除了主鍵外沒有任何二級索引第三步給表增加了一個最小的int類型的二級索引用于覆蓋掃描把count(*)的執(zhí)行計劃從全表掃變成了index索引全掃第四步重新壓測耗時降到了0.4秒左右。不能說這就是最優(yōu)方案因為日志表的寫入量非常大額外維護一個索引也增加了寫入成本。所以后來我們又加了一層優(yōu)化業(yè)務側把“最近7天日志條數”改成“近似條數”使用緩存方案不再查詢數據庫實時統計。最終接口響應時間從2秒壓到了100毫秒以內。5. 高頻踩坑與面試細節(jié)速查最后這點內容是給那些正在準備面試或者剛接手舊項目的同學看的。count函數的坑隱蔽性強很多線上數據對不上的事故查到最后才發(fā)現是count用法的問題。5.1 空值統計與NULL處理的陷阱這里有一個極容易翻車的例子。假設有一張用戶表user_info其中字段user_name允許NULL你需要統計“全部用戶和填寫了用戶名的用戶數量”寫了下面兩條SQLSELECT COUNT(*), COUNT(user_name) FROM user_info;如果你的數據里恰好有三行user_name為NULL最終返回的結果可能就是“10, 7”很多業(yè)務方看到這個結果直接蒙了認為數據庫出bug了。根本原因就是count(user_name)不統計NULL這個坑我在公司至少講過三遍。還有個小細節(jié)count(列名)判斷的是NULL不是空字符串。如果user_name字段填充了一個空字符串這個行會被count(user_name)統計進去因為空字符串不是NULL。想要排除空字符串必須寫成sum(case when user_name is not null and user_name ! then 1 else 0 end)。5.2 count(distinct 列名)的代價與優(yōu)化思路count(distinct 列名)看起來好用它的底層代價卻非常大要先對目標列進行排序或使用哈希去重然后再統計。數據量一大這條SQL的響應時間可能是普通count的十倍不止。我曾經在500萬行上執(zhí)行count(distinct user_id)整整跑了8秒多。如果業(yè)務確實需要高頻統計去重后的數量一種優(yōu)化方案是使用近似去重函數比如MySQL的APPROX_COUNT_DISTINCT8.0以上版本或者在大數據場景用HyperLogLog算法比如Redis的PFCOUNT命令。它們都能犧牲極小的精確度換來近乎實時的統計性能對報表場景來說性價比非常高。還有一種場景是只需要知道某個值是否存在比如“這個user_id是否出現在表里”那就別用count改用EXISTS它在找到第一條匹配記錄后就會停止掃描性能遠超count。5.3 面試高頻追問與回答思路面試官問count的區(qū)別其實不只是在考察你記沒記住結論更深層的意圖是想看你對數據庫底層實現機制的理解程度?？偨Y幾個高頻追問第一“為什么MyISAM的count(*)不用掃描”前面已經說過答案是MyISAM在元數據里緩存了總行數執(zhí)行時直接讀取?？疾禳c在于是否了解兩種存儲引擎的根本差異。第二“InnoDB的count(*)一定比count(1)慢嗎”正確答案是不一定現代優(yōu)化器會把兩者編譯成相同的執(zhí)行計劃?？疾禳c在于是否迷信舊有經驗。第三“count(id)用的是主鍵索引count(*)也用的主鍵嗎”答案是優(yōu)化器會選擇最短的二級索引去掃如果沒有合適的二級索引才掃主鍵索引。考察點在于是否真正理解索引選擇機制。第四“為什么建議把count(*)寫進規(guī)范而不是count(1)”參考答案是語義表達清晰、沒有性能劣勢、代碼可讀性好。考察點在于項目經驗里是否有代碼規(guī)范意識。6. 一句總結外加實操建議我在實際項目中見過太多因為count用錯導致的數據事故所以給自己帶的技術小組定了三條規(guī)矩第一統計總數一律用count()誰寫count(1)誰去復查表結構第二統計有值數量必須明確字段語義先查該列是否存在NULL再寫count(列名)第三大表count必須走優(yōu)化方案線上代碼里禁止裸查億級大表的count()。最后再分享一個調優(yōu)技巧如果你用的是InnoDB又確實需要在幾千萬行的表上頻繁統計總數與其糾結count函數本身不如花點時間設計一個短字段索引或者改造成緩存預統計方案。我在實踐里試過很多方法后者對接口響應速度的提升最為立竿見影。希望這篇內容能幫你把count函數徹底吃透下次再遇到相關SQL問題直接照著這些原則處理就行。