今日推薦

騰訊二面：@Bean 與 @Component 用在同一個(gè)類上，會(huì)怎么樣？比 Xshell 還好用的 SSH 客戶端神器，MobaXterm 太愛(ài)了！SpringBoot 如何統(tǒng)計(jì)、監(jiān)控 SQL運(yùn)行情況？SpringBoot 那些自帶 Buff 的工具類，你用過(guò)幾個(gè)？最新 955 不加班的公司名單（2022版）字節(jié)跳動(dòng)P0級(jí)事故：實(shí)習(xí)生刪除GB以下所有模型，直接上了今日頭條......

MySQL count(1) 真的比 count(*) 快么??

你也一直和我一樣認(rèn)為 count(1) 真的比 count(*) 快么？突然有一天和同事聊這個(gè)事情，被狠狠的鄙視了一把。

那么你自己研究過(guò)沒(méi)？如果我告訴你他們一樣，你信么？

有?Where?條件的?count，會(huì)根據(jù)掃碼結(jié)果count?一下所有的行數(shù)，其性能更依賴于你的?Where?條件，所以文章我們僅針對(duì)沒(méi)有?Where?的情況進(jìn)行說(shuō)明。

MyISAM 引擎會(huì)把一個(gè)表的總行數(shù)記錄了下來(lái)，所以在執(zhí)行?count(*)?的時(shí)候會(huì)直接返回?cái)?shù)量，執(zhí)行效率很高。在 MySQL 5.5 以后默認(rèn)引擎切換為 InnoDB，InnoDB 因?yàn)樵黾恿税姹究刂?MVCC)的原因，同時(shí)有多個(gè)事務(wù)訪問(wèn)數(shù)據(jù)并且有更新操作的時(shí)候，每個(gè)事務(wù)需要維護(hù)自己的可見(jiàn)性，那么每個(gè)事務(wù)查詢到的行數(shù)也是不同的，所以不能緩存具體的行數(shù)，他每次都需要?count?一下所有的行數(shù)。那么?count(1)?和?count(*)有區(qū)別么？

InnoDB handles SELECT COUNT(*) and SELECT COUNT(1) operations in the same way. There is no performance difference.?這是官網(wǎng)的解釋，直接點(diǎn)擊閱讀原文查看官文，所以兩種實(shí)現(xiàn)其實(shí)一樣，那么具體為什么一樣呢？

探究這個(gè)問(wèn)題首先我們需要理解?count?的含義，如下是官網(wǎng)給出的定義

Returns a count of the number of non-NULL values of expr in the rows retrieved by a SELECT statement. The result is a BIGINT value.

大致的解釋是返回 SELECT 語(yǔ)句檢索的行中 expr 的非 NULL 值的計(jì)數(shù)，到這里我們就明白了，首先它是一個(gè)聚合函數(shù)，然后對(duì) SELECT 的結(jié)果集進(jìn)行計(jì)數(shù)，但是需要參數(shù)不為 NULL。那么我們繼續(xù)閱讀官網(wǎng)的內(nèi)容：

COUNT(*) is somewhat different in that it returns a count of the number of rows retrieved, whether or not they contain NULL values.

大致的內(nèi)容是說(shuō)，count(*) 不同，他不關(guān)心這個(gè)返回值是否為空都會(huì)計(jì)算他的count，因?yàn)?count(1) 中的 1 是恒真表達(dá)式，那么 count(*) 還是 count(1) 都是對(duì)所有的結(jié)果集進(jìn)行 count，所以他們本質(zhì)上沒(méi)有什么區(qū)別。

當(dāng)然這個(gè)地方 InnoDB 本身也做了一些優(yōu)化，它會(huì)使用最小的二級(jí)索引來(lái)進(jìn)行?count?的查詢優(yōu)化。如果沒(méi)有二級(jí)索引才會(huì)選擇聚簇索引，這樣的設(shè)計(jì)單從 IO 的角度就節(jié)省了很多開(kāi)銷。

到這里我們明白了 count(*) 和 count(1) 本質(zhì)上面其實(shí)是一樣的，那么 count(column) 又是怎么回事呢？

count(column) 也是會(huì)遍歷整張表，但是不同的是它會(huì)拿到 column 的值以后判斷是否為空，然后再進(jìn)行累加，那么如果針對(duì)主鍵需要解析內(nèi)容，如果是二級(jí)所以需要再次根據(jù)主鍵獲取內(nèi)容，又是一次 IO 操作，所以 count(column) 的性能肯定不如前兩者嘍，如果按照效率比較的話：count(*)=count(1)>count(primary key)>count(column)

既然 count(*) 在查詢上依賴于所有的數(shù)據(jù)集，是不是我們?cè)谠O(shè)計(jì)上也需要盡量的規(guī)避全量 count 呢？通常情況我們針對(duì)可預(yù)見(jiàn)的 count 查詢會(huì)做適當(dāng)?shù)木彺?#xff0c;可以是 Redis，也可以是獨(dú)立的 MySQL count 表，當(dāng)然無(wú)論是哪種方式我們都需要考慮一致性的問(wèn)題。

到這里文章就結(jié)束了，你對(duì) count() 有了重新的認(rèn)識(shí)么？文中提到了一些關(guān)鍵字：聚簇索引、InnoDB、MyISAM、MVCC 不是本文的重點(diǎn)，有興趣可以持續(xù)關(guān)注訂閱號(hào)或置頂，后面會(huì)針對(duì)這些關(guān)鍵字逐一展開(kāi)說(shuō)明。

最后，再給大家推薦一個(gè)GitHub項(xiàng)目，該項(xiàng)目整理了上千本常用技術(shù)PDF，技術(shù)書籍都可以在這里找到。

GitHub地址：https://github.com/hello-go-maker/cs-books

電子書已經(jīng)更新好了，拿走不謝，記得點(diǎn)一個(gè)star，持續(xù)更新中...

總結(jié)

以上是生活随笔為你收集整理的一直认为 count(1) 比 count(*) 效果高，被同事鄙视了。的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。