在數(shù)據(jù)庫(kù)查詢(xún)中，count(*) 和 count(1) 是兩個(gè)常見(jiàn)的計(jì)數(shù)表達(dá)式，都可以用來(lái)計(jì)算表中行數(shù)。
很多人都以為 count(*) 效率更差，主要是因?yàn)樵谠缙诘臄?shù)據(jù)庫(kù)系統(tǒng)中，count(*) 可能會(huì)被實(shí)現(xiàn)為對(duì)所有列進(jìn)行掃描，而 count(1) 則可能只掃描單個(gè)列。
但事實(shí)真是如此嗎？
執(zhí)行原理
先來(lái)看看這兩者的執(zhí)行原理：
count(*) 查詢(xún)所有滿足條件的行，包括包含空值的行。在大多數(shù)數(shù)據(jù)庫(kù)中，count(*) 會(huì)直接統(tǒng)計(jì)行數(shù)，并不會(huì)實(shí)際去讀取每行中的詳細(xì)數(shù)據(jù)，因?yàn)閿?shù)據(jù)庫(kù)引擎會(huì)自行優(yōu)化該計(jì)數(shù)操作，以提高執(zhí)行效率。
count(1) 也是計(jì)算表中的行數(shù)，這里的 1 是一個(gè)常量，只是作為一個(gè)占位符，并沒(méi)有實(shí)際的含義。與 count(*) 類(lèi)似，數(shù)據(jù)庫(kù)引擎也會(huì)對(duì) count(1) 進(jìn)行優(yōu)化，以快速確定表中的行數(shù)。
count(*) 和 count(1) 的 性能差異
再說(shuō)性能，在大多數(shù)數(shù)據(jù)庫(kù)中，其實(shí) count(*) 和 count(1) 的性能非常相似，甚至可以說(shuō)沒(méi)有區(qū)別，這是因?yàn)榇蠖鄶?shù)數(shù)據(jù)庫(kù)引擎對(duì)這兩種計(jì)數(shù)方式進(jìn)行相同的優(yōu)化，并沒(méi)有明顯的執(zhí)行效率上的差異。但是在特殊情況下可能會(huì)有細(xì)微的差異，造成這種差異的原因通常有以下幾種：
1. 數(shù)據(jù)庫(kù)引擎的差異
不同的數(shù)據(jù)庫(kù)引擎可能對(duì) count(*) 和 count(1) 采取不同的優(yōu)化策略，這在某些情況下可能會(huì)導(dǎo)致兩種計(jì)數(shù)方式的性能差異。例如：
-
- SQL Server：在某些版本的 SQL Server 中，
count(1) 在特定的查詢(xún)計(jì)劃中可能稍微快一些，但這種差異通常微乎其微，只有在處理非常大的表或復(fù)雜查詢(xún)時(shí)才會(huì)顯現(xiàn)出來(lái)。 -
- MyISAM 引擎：在不附加任何
WHERE 查詢(xún)條件的情況下，統(tǒng)計(jì)表的總行數(shù)會(huì)非常快，因?yàn)?MyISAM 會(huì)用一個(gè)變量存儲(chǔ)表的行數(shù)。如果沒(méi)有 WHERE 條件，查詢(xún)語(yǔ)句將直接返回該變量值，使得速度很快。然而，只有當(dāng)表的第一列定義為 NOT NULL 時(shí)，count(1) 才能得到類(lèi)似的優(yōu)化。如果有 WHERE 條件，則該優(yōu)化將不再適用。 -
- InnoDB 引擎：盡管 InnoDB 表也存儲(chǔ)了一個(gè)記錄行數(shù)的變量，但遺憾的是，這個(gè)值只是一個(gè)估計(jì)值，并無(wú)實(shí)際意義。在 Innodb 引擎下，
count(*) 和 count(1) 哪個(gè)快呢？結(jié)論是：這倆在高版本的 MySQL 是沒(méi)有什么區(qū)別的，也就沒(méi)有 count(1) 會(huì)比 count(*) 更快這一說(shuō)了。 -
另外，還有一個(gè)問(wèn)題是 Innodb 是通過(guò)主鍵索引來(lái)統(tǒng)計(jì)行數(shù)的嗎？
如果該表只有一個(gè)主鍵索引，沒(méi)有任何二級(jí)索引的情況下，那么 count(*) 和 count(1) 都是通過(guò)通過(guò)主鍵索引來(lái)統(tǒng)計(jì)行數(shù)的。
如果該表有二級(jí)索引，則 count(*) 和 count(1) 都會(huì)通過(guò)占用空間最小的字段的二級(jí)索引進(jìn)行統(tǒng)計(jì)。
2. 索引的影響
如果表上有合適的索引，無(wú)論是count(1) 還是 count(*) 都可以利用索引來(lái)快速確定行數(shù)，而不必掃描整個(gè)表。在這種情況下，兩者的性能差異通常可以忽略不計(jì)。例如，如果有一個(gè)基于主鍵的索引，數(shù)據(jù)庫(kù)可以快速通過(guò)索引確定表中的行數(shù)，而無(wú)需讀取表中的每一行數(shù)據(jù)。
實(shí)戰(zhàn)分析
話不多說(shuō)，下面我們通過(guò)實(shí)驗(yàn)來(lái)驗(yàn)證上述理論：
第一步：創(chuàng)建表與插入數(shù)據(jù)
用 Chat2DB 給我們生成一個(gè)創(chuàng)建表的 sql 語(yǔ)句，直接用自然語(yǔ)言描述我們想要的字段名和字段類(lèi)型即可生成建表語(yǔ)句，也可以生成測(cè)試數(shù)據(jù)。
然后用存儲(chǔ)過(guò)程向 student 表中插入兩萬(wàn)條測(cè)試數(shù)據(jù)。（存儲(chǔ)過(guò)程執(zhí)行兩次）
插入數(shù)據(jù)后的 student 表如下：
這個(gè)時(shí)候執(zhí)行 select count(*) from student 和 select count(1) from student 可以看到解釋器的結(jié)果如下，耗時(shí)均為 2 ms（兩者一致，所以就只截了一張圖），兩者都用主鍵索引進(jìn)行行數(shù)的統(tǒng)計(jì)：
第二步：執(zhí)行計(jì)數(shù)查詢(xún)
創(chuàng)建二級(jí)索引 IDCard 進(jìn)行統(tǒng)計(jì)結(jié)果如下：
可以看出用二級(jí)索引進(jìn)行統(tǒng)計(jì)的解釋器結(jié)果還是一致。
結(jié)論
綜上所述，count(1) 和 count(*) 的性能基本相同，并不存在 COUNT(1) 比 COUNT(*) 更快的說(shuō)法?？傮w而言，在大多數(shù)情況下，兩者之間的性能差異是可以忽略不計(jì)的。
在選擇使用哪種方式時(shí)，應(yīng)當(dāng)優(yōu)先考慮代碼的可讀性和可維護(hù)性。count(*) 在語(yǔ)義上更為明確，表示計(jì)算所有行的數(shù)量，而不依賴(lài)于任何特定的值。因此，從代碼清晰度的角度出發(fā)，通常建議優(yōu)先使用 count(*)。
當(dāng)然，如果在特定的數(shù)據(jù)庫(kù)環(huán)境中，經(jīng)過(guò)實(shí)際測(cè)試發(fā)現(xiàn) count(1) 具有明顯的性能優(yōu)勢(shì)，那么也可以選擇使用 count(1)。但在一般情況下，不必過(guò)分糾結(jié)于這兩種計(jì)數(shù)方式之間的性能差異。
希望本文能幫助你在使用計(jì)數(shù)操作時(shí)作出更為合理的選擇。
：count(1) 和 count(*)哪個(gè)性能更好？
400 186 1886
