1. 先搞清楚三兄弟的本質(zhì)它們真的不一樣嗎很多同學(xué)剛接觸SQL時就被教育“count(1)、count(*)和count(列名)只是寫法不同效果一樣”結(jié)果一用就踩坑。這個說法只對了一半甚至可以說這個“簡化結(jié)論”坑了不少人。先把三兄弟的定義擺清楚count(1)對每一行計(jì)數(shù)碰到任何字面量1都算一行不管這一行其他列是什么值。count(*)對滿足WHERE條件的整個行集合計(jì)數(shù)和count(1)本質(zhì)相同都是“按行統(tǒng)計(jì)”。count(列名)只統(tǒng)計(jì)該列“非NULL”的行數(shù)NULL值直接跳過。一個最容易出錯的日常場景統(tǒng)計(jì)訂單表里“有收貨地址”的訂單數(shù)直接寫count(address)就能得到正確答案因?yàn)镹ULL地址自動被忽略但如果改寫成count(1)所有訂單都會被統(tǒng)計(jì)進(jìn)去業(yè)務(wù)口徑就錯了。這就是三者最核心的區(qū)別弄不明白這個后面的性能討論全是空中樓閣。從數(shù)據(jù)庫實(shí)現(xiàn)層面看主流的MySQL InnoDB、PostgreSQL、SQL Server、Oracle對count(*)和count(1)的物理執(zhí)行路徑基本一致都是統(tǒng)計(jì)掃描區(qū)間內(nèi)的行數(shù)優(yōu)化器甚至?xí)裞ount(1)重寫為count(*)。而count(列名)則完全不同它需要檢查每一行的列值是否為NULL這決定了它的語義和性能都會走在另一條路上。2. 核心差異COUNT函數(shù)與NULL值的恩怨情仇2.1 count(列名)遇到NULL時的硬規(guī)則SQL標(biāo)準(zhǔn)規(guī)定COUNT(列名)只統(tǒng)計(jì)該列中非NULL值的數(shù)量。這不是某個數(shù)據(jù)庫的行為差異而是所有遵循SQL標(biāo)準(zhǔn)的數(shù)據(jù)庫共同遵守的規(guī)則。很多新手在業(yè)務(wù)統(tǒng)計(jì)中出錯基本都是沒有意識到“NULL不等于0、也不等于空字符串”?？兆址怯兄礜ULL是“未知、不存在”兩者在COUNT函數(shù)里是完全不同的處理結(jié)果。舉個例子一張用戶表中有一列phone如果某行phone為NULL那這群用戶雖然沒有登記電話但仍然是用戶。用count(user_id)可以統(tǒng)計(jì)用戶總數(shù)用count(phone)統(tǒng)計(jì)的卻是“已登記電話的用戶數(shù)”兩個數(shù)字一比就能快速算出電話登記覆蓋率。這個用法在生產(chǎn)環(huán)境非常常見也是count(列名)不可替代的存在價值。2.2 count(*)與count(1)如何處理NULLcount(*)和count(1)不存在NULL跳過的問題它們統(tǒng)計(jì)的是“行數(shù)”跟行內(nèi)任何列的值都沒有關(guān)系。哪怕一行數(shù)據(jù)里所有列都是NULLcount(*)和count(1)依然會把它算進(jìn)去。這一點(diǎn)在“保持全表行數(shù)一致性”的場景極為重要比如核對數(shù)據(jù)遷移前后行數(shù)是否一致必須用count(*)絕不能用一個允許為NULL的列名做count。從語義上可以這么理解count(*)中的星號代表“整行”行存在就計(jì)數(shù)count(1)中的1只表示一個常量標(biāo)記和行內(nèi)容無關(guān)。2.3 坑爹的“為什么統(tǒng)計(jì)結(jié)果對不上”我見過一個真實(shí)的線上事故某運(yùn)營團(tuán)隊(duì)統(tǒng)計(jì)“昨日活躍用戶數(shù)”寫的是count(user_id)結(jié)果報表長期偏低因?yàn)椴糠钟脩魎ser_id字段在歷史數(shù)據(jù)中存在NULL當(dāng)年上線時沒做好約束導(dǎo)致這些用戶永遠(yuǎn)不被統(tǒng)計(jì)。排查了很久才發(fā)現(xiàn)是count語義問題不是數(shù)據(jù)缺失。后來統(tǒng)一改成count(*)配合user_id IS NOT NULL的WHERE條件才把問題根治。這個案例給我們的教訓(xùn)是先想清楚“你到底要數(shù)什么”再選擇函數(shù)?！皵?shù)所有行”用count(*) “數(shù)某列有多少非空值”用count(列名) 至于count(1)它跟count(*)等價刻意區(qū)分它倆沒有意義。3. 性能實(shí)戰(zhàn)到底誰最快別再被老謠言帶偏3.1 那些年流傳的“count(1)比count(*)快”是從哪來的網(wǎng)上大量舊文章宣稱“count(1)比count(*)快”這個說法源自古早的Oracle和SQL Server時代當(dāng)時優(yōu)化器執(zhí)行count(*)時可能要處理更多元數(shù)據(jù)信息或存在解析差異。但現(xiàn)代數(shù)據(jù)庫優(yōu)化器已經(jīng)很成熟執(zhí)行計(jì)劃根本不會因?yàn)槟闶?還是星號就改變路徑。MySQL 8.x里直接看執(zhí)行計(jì)劃可以發(fā)現(xiàn)count(1)會被重寫為count(*)的行為二者生成的執(zhí)行計(jì)劃和成本完全相同。那為什么還會有人信誓旦旦說自己測過count(1)更快大概率是測試時樣本太小、緩存未清、或者把執(zhí)行計(jì)劃差異歸因錯誤。如果真要測請?jiān)陉P(guān)閉查詢緩存的前提下用百萬級以上的數(shù)據(jù)表多測幾輪取平均值結(jié)果就會發(fā)現(xiàn)兩者差距幾乎為零。3.2 InnoDB引擎下count(*)的真實(shí)成本MySQL在MyISAM時代有個特殊優(yōu)化MyISAM表會把總行數(shù)作為元數(shù)據(jù)直接存下來count(*)不帶WHERE時根本不用掃表直接返回性能極高。但換成InnoDB后這個優(yōu)化被取消了因?yàn)镮nnoDB支持事務(wù)和MVCC不同事務(wù)看到的行數(shù)不一樣沒法像MyISAM那樣用一個固定數(shù)字糊弄所以InnoDB必須通過遍歷索引或掃描全表來實(shí)時計(jì)算行數(shù)。這也是為什么很多同學(xué)發(fā)現(xiàn)同樣的count語句在MyISAM表上秒回、在InnoDB上卻慢如蝸牛。InnoDB的優(yōu)化師退而求其次選擇掃描“最小的可用索引”來減少IO成本而非強(qiáng)制掃描主鍵聚簇索引。比如一張表主鍵是bigint同時還有一個CHAR(200)的索引InnoDB會優(yōu)先挑小的二級索引掃描因?yàn)槎壦饕~子節(jié)點(diǎn)只存索引列主鍵占的空間小IO更少。所以你在給表加索引時如果預(yù)期會頻繁count全表可以專門設(shè)計(jì)一個小字段索引來加速統(tǒng)計(jì)類似count優(yōu)化測試表。3.3 count(列名)為什么可能更慢count(列名)的性能下限取決于目標(biāo)列是否在索引中。如果統(tǒng)計(jì)的列恰好有二級索引MySQL會通過掃描該索引判斷NULL性能尚可但如果統(tǒng)計(jì)的列沒有索引那就只能對聚集索引做全表掃描每讀一行都要取一遍目標(biāo)列的值做判斷IO開銷直接拉滿。更糟的情況是統(tǒng)計(jì)多列JOIN結(jié)果中的某個大文本列每一行還要解析變長字段存儲信息CPU和內(nèi)存開銷同步上升。實(shí)測參考值一張500萬行的InnoDB表非索引列count(列名)用了我2.3秒而count(*)只用了0.6秒。差距來源不是優(yōu)化器魔法而是count(列名)必須額外讀取目標(biāo)列內(nèi)容來判斷是否為NULL無法像count(*)那樣只要“數(shù)行”就完事。因此如果只是要總數(shù)永遠(yuǎn)別用count(列名)。4. 實(shí)操指南不同場景下到底該用哪個4.1 無腦選型清單日常寫SQL時可以直接按下面這個決策路徑來選要查表的總行數(shù)不管某列是否NULL用count(*)這是最穩(wěn)妥、最通用的寫法。要查某列非NULL值的數(shù)量用count(列名)比如“有郵箱的用戶數(shù)”“補(bǔ)全了身份證號的記錄數(shù)”。要查不重復(fù)值的數(shù)量count(distinct 列名)注意distinct和NULL的交互MySQL里count(distinct 列名)同樣忽略NULL。配合判斷記錄是否存在時更好用 count(*) LIMIT 1 的變體比如 EXISTS而不是把整個大表count一遍。4.2 業(yè)務(wù)統(tǒng)計(jì)中的經(jīng)典組合拳口徑一統(tǒng)計(jì)頁面訪問總量。訪問日志表的session_id列可能存在NULL比如未登錄用戶沒有session需求是“統(tǒng)計(jì)所有訪問行為”就必須count(*)而不是count(session_id)。我見過有人在這上面犯過錯把匿名訪問全部漏掉導(dǎo)致PV數(shù)字直接少了一截?？趶蕉y(tǒng)計(jì)成功支付訂單量。支付表里pay_time允許為NULL只有成功支付才寫入時間。這時候count(pay_time)就能直接給出成功支付訂單數(shù)省掉了WHERE pay_time IS NOT NULL的條件。注意這里雖然結(jié)果等價但業(yè)務(wù)語義清晰閱讀代碼的人一眼能懂?？趶饺y(tǒng)計(jì)有效會員數(shù)。is_deleted字段標(biāo)記是否刪除0為正常1為已刪除。如果要用count(列名)只能統(tǒng)計(jì)is_deleted非NULL的數(shù)量但NULL并不會等于0所以這種情況直接用WHERE再count(*)更清晰。4.3 count與GROUP BY、DISTINCT搭配的進(jìn)階玩法GROUP BY 和 count(*)搭配是統(tǒng)計(jì)報表最常見的組合例如按城市統(tǒng)計(jì)用戶數(shù)SELECT city, count(*) FROM users GROUP BY city; 這里count(*)統(tǒng)計(jì)的是每組內(nèi)的行數(shù)是SQL標(biāo)準(zhǔn)中完全正確的用法。再說說count(distinct 列名)它的語義是“該列有多少個不同的非NULL值”。在用戶畫像統(tǒng)計(jì)里需要計(jì)算“有多少個不同的省份”直接count(distinct province)即可。要注意的是distinct的開銷會比普通count大得多它需要在執(zhí)行期間維護(hù)一個去重集合數(shù)據(jù)量大時內(nèi)存占用明顯。必要時可以拆兩步先SELECT DISTINCT縮小數(shù)據(jù)集再在外面套一層count對復(fù)雜去重統(tǒng)計(jì)反而更可控。還有人喜歡用count(distinct a, b)來做多列組合去重統(tǒng)計(jì)這個語法在MySQL和SQL Server都支持但需要關(guān)注各數(shù)據(jù)庫對NULL的處理差異。MySQL里只要組合中有一個NULL就不計(jì)數(shù)而這個細(xì)節(jié)在不同數(shù)據(jù)庫中可能不同跨庫遷移時一定要驗(yàn)證。5. 常見問題與排查技巧實(shí)錄5.1 為什么count(列名)統(tǒng)計(jì)結(jié)果和別人不一樣最常見的答案是NULL處理差異。你和同事用了不同的列甚至同一列但包含NULL數(shù)據(jù)結(jié)果自然不同。排查時不要光看數(shù)字先確認(rèn)口徑統(tǒng)計(jì)的是“行數(shù)”還是“非空值個數(shù)”。如果目標(biāo)列本身允許NULL常規(guī)方案是統(tǒng)一口徑為“非空值計(jì)數(shù)”并在SQL注釋里寫明防止后人誤改。另一個隱蔽問題是字符集和排序規(guī)則差異某些數(shù)據(jù)庫里大小寫敏感或全半角符號處理不同會導(dǎo)致count(distinct 列名)結(jié)果與業(yè)務(wù)預(yù)期不符這時候要檢查列的COLLATION設(shè)置。5.2 大表count卡死怎么辦當(dāng)表數(shù)據(jù)量達(dá)到千萬級即使count(*)走最小索引掃描也可能要數(shù)秒甚至數(shù)十秒。如果你的業(yè)務(wù)是儀表盤大屏要“秒出總行數(shù)”標(biāo)準(zhǔn)解法是引入計(jì)數(shù)表維護(hù)一張meta表每次INSERT/DELETE時通過事務(wù)同步更新總行數(shù)字段。這個方案常用于數(shù)據(jù)倉庫匯總層或用戶前臺展示例如商品列表頁頂部展示“共xx件商品”完全沒必要每次實(shí)時掃全表。頻率高但不是極度敏感的場景也可以用Redis做異步計(jì)數(shù)定期掃描增量核對。注意計(jì)數(shù)表方案要考慮并發(fā)修改沖突必須把“更新計(jì)數(shù)”和“寫入數(shù)據(jù)”放在同一個事務(wù)里或者依賴數(shù)據(jù)庫行鎖來保證一致。5.3 推薦一個排查count慢的完整思路如果你接手了一個運(yùn)行緩慢的count查詢按下面順序排查基本能定位80%的問題先看執(zhí)行計(jì)劃確認(rèn)走的是主鍵掃描還是某個二級索引掃描。如果全表掃描且表巨大優(yōu)先考慮加覆蓋索引。確認(rèn)是否存在WHERE條件下推失敗比如在索引列上使用了函數(shù)WHERE DATE(create_time)...導(dǎo)致索引失效count被迫掃全表。看是否有行鎖競爭count查詢在InnoDB默認(rèn)加的是快照讀不阻塞其他會話寫入。但如果配合UPDATE則可能阻塞要檢查并發(fā)量。檢查被統(tǒng)計(jì)列的數(shù)據(jù)分布如果絕大部分行都是NULLcount(列名)依然會把整張表掃一遍并不會因?yàn)镹ULL多而加速。如果目標(biāo)只是“粗略估算行數(shù)”可以借助information_schema.tables里的TABLE_ROWS字段它只是一個優(yōu)化器估算值不精確但作為容量監(jiān)控和趨勢判斷完全夠用。5.4 后端程序員最常犯的三個錯誤第一個錯誤是拿count(1)當(dāng)“按值統(tǒng)計(jì)”。比如要統(tǒng)計(jì)狀態(tài)字段為有效的數(shù)據(jù)卻寫成了count(status1)這是典型理解偏差因?yàn)閏ount的參數(shù)表達(dá)式只要是常量就算一行不會篩選正確寫法是count(*)加WHERE。第二個錯誤是統(tǒng)計(jì)“不重復(fù)的用戶數(shù)”時寫count(user_name)卻忽略了user_name可能存在NULL正確寫法是count(distinct user_name)。第三個錯誤是在JOIN查詢里下意識寫count(*)結(jié)果發(fā)現(xiàn)行數(shù)膨脹了一倍因?yàn)镴OIN產(chǎn)生的是笛卡爾積中間結(jié)果。這種情況下要看清楚需求如果統(tǒng)計(jì)主表行數(shù)先對子查詢?nèi)ブ卦賑ount或者使用count(distinct 主表主鍵)。6. 最后再分享一點(diǎn)我的實(shí)踐經(jīng)驗(yàn)回頭看這個看似基礎(chǔ)的問題我的體會是SQL入門越早的概念越容易被“簡化記憶”糊弄過去而count三兄弟就是重災(zāi)區(qū)。count(*)、count(1)、count(列名)絕不是隨便換著用的等價寫法它們涉及SQL標(biāo)準(zhǔn)對NULL的定義、數(shù)據(jù)庫引擎的索引選擇、業(yè)務(wù)統(tǒng)計(jì)口徑的一致性。我建議每個接手?jǐn)?shù)據(jù)統(tǒng)計(jì)任務(wù)的開發(fā)者先花兩分鐘看清數(shù)據(jù)模型里哪些列允許NULL哪些列是邏輯刪除標(biāo)記再決定用哪個count。把這一步養(yǎng)成習(xí)慣能少踩很多報表數(shù)據(jù)的坑。如果你當(dāng)前的表是MySQL InnoDB且數(shù)據(jù)量已經(jīng)上了千萬又需要頻繁統(tǒng)計(jì)總行數(shù)我個人強(qiáng)烈建議引入計(jì)數(shù)表方案而不是一次次在慢查詢?nèi)罩纠飺七@條秒級SQL。最后再提醒一句所有測試count性能的場合先清緩存、多跑幾輪、再對比執(zhí)行計(jì)劃不要拿一次偶然結(jié)果下結(jié)論。