不就是SELECT COUNT語句嗎,竟然能被面試官虐的體無完膚

數據庫查詢相信很多人都不陌生,所有經常有人調侃程序員就是CRUD專員,這所謂的CRUD指的就是數據庫的增刪改查。

在數據庫的增刪改查操作中,使用最頻繁的就是查詢操作。而在所有查詢操作中,統計數量操作更是經常被用到。

關于數據庫中行數統計,無論是MySQL還是Oracle,都有一個函數可以使用,那就是COUNT。

但是,就是這個常用的COUNT函數,卻暗藏著很多玄機,尤其是在面試的時候,一不小心就會被虐。不信的話請嘗試回答下以下問題:

1、COUNT有幾種用法?

2、COUNT(字段名)和COUNT(*)的查詢結果有什么不同?

3、COUNT(1)和COUNT(*)之間有什么不同?

4、COUNT(1)和COUNT(*)之間的效率哪個更高?

5、為什么《阿里巴巴Java開發手冊》建議使用COUNT(*)

6、MySQL的MyISAM引擎對COUNT(*)做了哪些優化?

7、MySQL的InnoDB引擎對COUNT(*)做了哪些優化?

8、上面提到的MySQL對COUNT(*)做的優化,有一個關鍵的前提是什么?

9、SELECT COUNT(*) 的時候,加不加where條件有差別嗎?

10、COUNT(*)、COUNT(1)和COUNT(字段名)的執行過程是怎樣的?

以上10道題,如果您可以全部準確無誤的回答的話,那說明你真的很了解COUNT函數了,如果有哪些知識點是不了解的,那么本文正好可以幫你答疑解惑。

認識COUNT

關于COUNT函數,在MySQL官網中有詳細介紹:

簡單翻譯一下:

1、COUNT(expr) ,返回SELECT語句檢索的行中expr的值不為NULL的數量。結果是一個BIGINT值。

2、如果查詢結果沒有命中任何記錄,則返回0

3、但是,值得注意的是,COUNT(*) 的統計結果中,會包含值為NULL的行數。

即以下表記錄

create table #bla(id int,id2 int)
insert #bla values(null,null)
insert #bla values(1,null)
insert #bla values(null,1)
insert #bla values(1,null)
insert #bla values(null,1)
insert #bla values(1,null)
insert #bla values(null,null)
復制代碼

使用語句count(*),count(id),count(id2)查詢結果如下:

select count(*),count(id),count(id2)
from #bla
results 7 3 2
復制代碼

除了COUNT(id)COUNT(*)以外,還可以使用COUNT(常量)(如COUNT(1))來統計行數,那么這三條SQL語句有什么區別呢?到底哪種效率更高呢?為什么《阿里巴巴Java開發手冊》中強制要求不讓使用 COUNT(列名)COUNT(常量)來替代 COUNT(*)呢?

COUNT(列名)、COUNT(常量)和COUNT(*)之間的區別

前面我們提到過COUNT(expr)用于做行數統計,統計的是expr不為NULL的行數,那么COUNT(列名)COUNT(常量)COUNT(*)這三種語法中,expr分別是列名常量*

那么列名常量*這三個條件中,常量 是一個固定值,肯定不為NULL。*可以理解為查詢整行,所以肯定也不為NULL,那么就只有列名的查詢結果有可能是NULL了。

所以, COUNT(常量)COUNT(*)表示的是直接查詢符合條件的數據庫表的行數。而COUNT(列名)表示的是查詢符合條件的列的值不為NULL的行數。

除了查詢得到結果集有區別之外,COUNT(*)相比COUNT(常量)COUNT(列名)來講,COUNT()是SQL92定義的標準統計行數的語法,因為他是標準語法,所以MySQL數據庫對他進行過很多優化。*

SQL92,是數據庫的一個ANSI/ISO標準。它定義了一種語言(SQL)以及數據庫的行為(事務、隔離級別等)。

COUNT(*)的優化

前面提到了COUNT(*)是SQL92定義的標準統計行數的語法,所以MySQL數據庫對他進行過很多優化。那么,具體都做過哪些事情呢?

這里的介紹要區分不同的執行引擎。MySQL中比較常用的執行引擎就是InnoDB和MyISAM。

MyISAM和InnoDB有很多區別,其中有一個關鍵的區別和我們接下來要介紹的COUNT(*)有關,那就是MyISAM不支持事務,MyISAM中的鎖是表級鎖;而InnoDB支持事務,并且支持行級鎖。

因為MyISAM的鎖是表級鎖,所以同一張表上面的操作需要串行進行,所以,MyISAM做了一個簡單的優化,那就是它可以把表的總行數單獨記錄下來,如果從一張表中使用COUNT()進行查詢的時候,可以直接返回這個記錄下來的數值就可以了,當然,前提是不能有where條件。*

MyISAM之所以可以把表中的總行數記錄下來供COUNT(*)查詢使用,那是因為MyISAM數據庫是表級鎖,不會有并發的數據庫行數修改,所以查詢得到的行數是準確的。

但是,對于InnoDB來說,就不能做這種緩存操作了,因為InnoDB支持事務,其中大部分操作都是行級鎖,所以可能表的行數可能會被并發修改,那么緩存記錄下來的總行數就不準確了。

但是,InnoDB還是針對COUNT(*)語句做了些優化的。

在InnoDB中,使用COUNT(*)查詢行數的時候,不可避免的要進行掃表了,那么,就可以在掃表過程中下功夫來優化效率了。

從MySQL 8.0.13開始,針對InnoDB的SELECT COUNT(*) FROM tbl_name語句,確實在掃表的過程中做了一些優化。前提是查詢語句中不包含WHERE或GROUP BY等條件。

我們知道,COUNT()的目的只是為了統計總行數,所以,他根本不關心自己查到的具體值,所以,他如果能夠在掃表的過程中,選擇一個成本較低的索引進行的話,那就可以大大節省時間。*

我們知道,InnoDB中索引分為聚簇索引(主鍵索引)和非聚簇索引(非主鍵索引),聚簇索引的葉子節點中保存的是整行記錄,而非聚簇索引的葉子節點中保存的是該行記錄的主鍵的值。

所以,相比之下,非聚簇索引要比聚簇索引小很多,所以MySQL會優先選擇最小的非聚簇索引來掃表。所以,當我們建表的時候,除了主鍵索引以外,創建一個非主鍵索引還是有必要的。

至此,我們介紹完了MySQL數據庫對于COUNT(*)的優化,這些優化的前提都是查詢語句中不包含WHERE以及GROUP BY條件。

COUNT(*)和COUNT(1)

介紹完了COUNT(*),接下來看看COUNT(1),對于,這二者到底有沒有區別,網上的說法眾說紛紜。

有的說COUNT(*)執行時會轉換成COUNT(1),所以COUNT(1)少了轉換步驟,所以更快。

還有的說,因為MySQL針對COUNT(*)做了特殊優化,所以COUNT(*)更快。

那么,到底哪種說法是對的呢?看下MySQL官方文檔是怎么說的:

InnoDB handles SELECT COUNT(*) and SELECT COUNT(1) operations in the same way. There is no performance difference.

畫重點:same way , no performance difference所以,對于COUNT(1)和COUNT(),MySQL的優化是完全一樣的,根本不存在誰比誰快!*

那既然COUNT(*)COUNT(1)一樣,建議用哪個呢?

建議使用COUNT(*)!因為這個是SQL92定義的標準統計行數的語法,而且本文只是基于MySQL做了分析,關于Oracle中的這個問題,也是眾說紛紜的呢。

COUNT(字段)

最后,就是我們一直還沒提到的COUNT(字段),他的查詢就比較簡單粗暴了,就是進行全表掃描,然后判斷指定字段的值是不是為NULL,不為NULL則累加。

相比COUNT(*)COUNT(字段)多了一個步驟就是判斷所查詢的字段是否為NULL,所以他的性能要比COUNT(*)慢。

總結

本文介紹了COUNT函數的用法,主要用于統計表行數。主要用法有COUNT(*)COUNT(字段)COUNT(1)

因為COUNT(*)是SQL92定義的標準統計行數的語法,所以MySQL對他進行了很多優化,MyISAM中會直接把表的總行數單獨記錄下來供COUNT(*)查詢,而InnoDB則會在掃表的時候選擇最小的索引來降低成本。當然,這些優化的前提都是沒有進行where和group的條件查詢。

在InnoDB中COUNT(*)COUNT(1)實現上沒有區別,而且效率一樣,但是COUNT(字段)需要進行字段的非NULL判斷,所以效率會低一些。

因為COUNT(*)是SQL92定義的標準統計行數的語法,并且效率高,所以請直接使用COUNT(*)查詢表的行數!

參考資料: dev.mysql.com/doc/refman/… 《極客時間——MySQL實戰45講》

作者:HollisChuang
鏈接:https://juejin.im/post/5dad103a518825579a1f9aaf
來源:掘金

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,316評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,481評論 3 415
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,241評論 0 374
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,939評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,697評論 6 409
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,182評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,247評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,406評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,933評論 1 334
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,772評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,973評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,516評論 5 359
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,209評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,638評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,866評論 1 285
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,644評論 3 391
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,953評論 2 373

推薦閱讀更多精彩內容

  • 今天看到一位朋友寫的mysql筆記總結,覺得寫的很詳細很用心,這里轉載一下,供大家參考下,也希望大家能關注他原文地...
    信仰與初衷閱讀 4,746評論 0 30
  • MySQL不權威總結 歡迎閱讀 本文并非事無巨細的mysql學習資料,而是選擇其中重要、困難、易錯的部分進行系統地...
    liufxlucky365閱讀 2,612評論 0 26
  • 一、MySQL優化 MySQL優化從哪些方面入手: (1)存儲層(數據) 構建良好的數據結構。可以大大的提升我們S...
    寵辱不驚丶歲月靜好閱讀 2,454評論 1 8
  • 面試題5:union all 和 union的區別 Union:對兩個結果集進行并集操作,不包括重復行,同時進行默...
    行者和他的鋼筆閱讀 949評論 0 1
  • 有一群人,意氣風發; 逆風浴雨,伺機而動。 不曉得是第幾次來西湖公園了,但卻準確的記得是第二次來這里跑步,以一個刺...
    比卡丘之夢閱讀 428評論 0 0