一直認(rèn)為 count(1) 比 count(*) 效果高,被同事鄙視了革砸。

文章來源于公眾號碼匠筆記 除秀,作者碼匠筆記

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

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

那么你自己研究過沒?如果我告訴你他們一樣笔时,你信么棍好?

有 Where 條件的 count,會根據(jù)掃碼結(jié)果count 一下所有的行數(shù)允耿,其性能更依賴于你的 Where 條件借笙,所以文章我們僅針對沒有 Where 的情況進(jìn)行說明。

MyISAM 引擎會把一個表的總行數(shù)記錄了下來较锡,所以在執(zhí)行 count() 的時候會直接返回數(shù)量业稼,執(zhí)行效率很高。在 MySQL 5.5 以后默認(rèn)引擎切換為 InnoDB蚂蕴,InnoDB 因為增加了版本控制(MVCC)的原因低散,同時有多個事務(wù)訪問數(shù)據(jù)并且有更新操作的時候,每個事務(wù)需要維護自己的可見性骡楼,那么每個事務(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)的解釋,直接點擊閱讀原文查看官文篮条,所以兩種實現(xià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 語句檢索的行中 expr 的非 NULL 值的計數(shù)赴恨,到這里我們就明白了,首先它是一個聚合函數(shù)伴栓,然后對 SELECT 的結(jié)果集進(jìn)行計數(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)容是說,count() 不同除师,他不關(guān)心這個返回值是否為空都會計算他的count沛膳,因為 count(1) 中的 1 是恒真表達(dá)式,那么 count() 還是 count(1) 都是對所有的結(jié)果集進(jìn)行 count汛聚,所以他們本質(zhì)上沒有什么區(qū)別锹安。

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

到這里我們明白了 count(*) 和 count(1) 本質(zhì)上面其實是一樣的痕貌,那么 count(column) 又是怎么回事呢风罩?

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

既然 count(*) 在查詢上依賴于所有的數(shù)據(jù)集落追,是不是我們在設(shè)計上也需要盡量的規(guī)避全量 count 呢盈滴?通常情況我們針對可預(yù)見的 count 查詢會做適當(dāng)?shù)木彺妫梢允?Redis轿钠,也可以是獨立的 MySQL count 表巢钓,當(dāng)然無論是哪種方式我們都需要考慮一致性的問題。

到這里文章就結(jié)束了疗垛,你對 count() 有了重新的認(rèn)識么症汹?文中提到了一些關(guān)鍵字:聚簇索引、InnoDB继谚、MyISAM、MVCC 不是本文的重點阵幸,有興趣可以持續(xù)關(guān)注訂閱號或置頂花履,后面會針對這些關(guān)鍵字逐一展開說明。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末挚赊,一起剝皮案震驚了整個濱河市诡壁,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌荠割,老刑警劉巖妹卿,帶你破解...
    沈念sama閱讀 216,402評論 6 499
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件旺矾,死亡現(xiàn)場離奇詭異,居然都是意外死亡夺克,警方通過查閱死者的電腦和手機箕宙,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,377評論 3 392
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來铺纽,“玉大人柬帕,你說我怎么就攤上這事〗泼牛” “怎么了陷寝?”我有些...
    開封第一講書人閱讀 162,483評論 0 353
  • 文/不壞的土叔 我叫張陵,是天一觀的道長其馏。 經(jīng)常有香客問我凤跑,道長,這世上最難降的妖魔是什么叛复? 我笑而不...
    開封第一講書人閱讀 58,165評論 1 292
  • 正文 為了忘掉前任仔引,我火速辦了婚禮,結(jié)果婚禮上致扯,老公的妹妹穿的比我還像新娘肤寝。我一直安慰自己,他們只是感情好抖僵,可當(dāng)我...
    茶點故事閱讀 67,176評論 6 388
  • 文/花漫 我一把揭開白布鲤看。 她就那樣靜靜地躺著,像睡著了一般耍群。 火紅的嫁衣襯著肌膚如雪义桂。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,146評論 1 297
  • 那天蹈垢,我揣著相機與錄音慷吊,去河邊找鬼。 笑死曹抬,一個胖子當(dāng)著我的面吹牛溉瓶,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播谤民,決...
    沈念sama閱讀 40,032評論 3 417
  • 文/蒼蘭香墨 我猛地睜開眼堰酿,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了张足?” 一聲冷哼從身側(cè)響起触创,我...
    開封第一講書人閱讀 38,896評論 0 274
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎为牍,沒想到半個月后哼绑,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體岩馍,經(jīng)...
    沈念sama閱讀 45,311評論 1 310
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,536評論 2 332
  • 正文 我和宋清朗相戀三年抖韩,在試婚紗的時候發(fā)現(xiàn)自己被綠了蛀恩。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 39,696評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡帽蝶,死狀恐怖赦肋,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情励稳,我是刑警寧澤佃乘,帶...
    沈念sama閱讀 35,413評論 5 343
  • 正文 年R本政府宣布,位于F島的核電站驹尼,受9級特大地震影響趣避,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜新翎,卻給世界環(huán)境...
    茶點故事閱讀 41,008評論 3 325
  • 文/蒙蒙 一程帕、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧地啰,春花似錦愁拭、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,659評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至蔚鸥,卻和暖如春惜论,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背止喷。 一陣腳步聲響...
    開封第一講書人閱讀 32,815評論 1 269
  • 我被黑心中介騙來泰國打工馆类, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人弹谁。 一個月前我還...
    沈念sama閱讀 47,698評論 2 368
  • 正文 我出身青樓乾巧,卻偏偏與公主長得像,于是被迫代替她去往敵國和親预愤。 傳聞我的和親對象是個殘疾皇子沟于,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 44,592評論 2 353