MySQL實戰 | 14 為什么count(*)越來越慢?

select count(*) 應該是一個比較常用的語句,用來統計記錄行數。

但是,慢慢地你會發現,這個語句越來越慢了,為什么呢?

count(*) 的實現方式

首先,我們來看下它的實現方式。

MySQL 中,不同的存儲引擎,count(*) 的實現方式是不同的。

1、MyISAM 引擎,比較簡單粗暴,直接將表的總行數存儲在磁盤上,因此效率很高;

2、InnoDB 引擎中,執行時,需要一行行的把數據查出來,然后累加;

為啥 MyISAM 就可以這樣做呢?因為它不支持事務啊,不用擔心數據不一致的問題。

而 InnoDB 就不一樣了。

由于 MVCC 的存在,InnoDB 在當前執行環境下,對一共有多少數據行是不確定的,比如:

假設,表 t 中有 1000 條數據,有下面三個用戶并行的會話:

1、A 啟動事務,查詢表的總行數;
2、C 直接插入一條數據,然后查詢總行數;
3、B 啟動事務,插入一條數據,然后查詢總行數;
4、C 查詢總行數;

注意,上面啟動的事務都沒有提交。

image

A、B、C 查詢的結果都不相同。

B 讀到的是 1002,是因為可重復讀隔離級別的存在,而 C 未開啟事務,因此無法看到別的事務的更新;

綜上,InnoDB 引擎中,在每一個會話中,都需要逐行讀取數據,然后計數返回總行數。

InnoDB 對 count(*) 的優化

InnoDB 中,主鍵索引存儲的是數據,輔助索引存儲的只是主鍵值。

因此,輔助索引比主鍵索引小得多,輕量得多。

這種情況下,InnoDB 在執行 count(*) 時,就會判斷使用哪個索引,會選擇最小的樹來進行遍歷。

在保證邏輯正確的前提下,盡量減少掃描的數據量,是數據庫系統設計的通用法則之一。

小結

1、由于 MyISAM 引擎不需要支持事務,因此可以快速返回 count(*)
2、show table status 命令雖然返回很快,但是不準確;
3、InnoDB 執行 count(*) 時會遍歷全表,因此性能較差;

count(*)、count(1)、count(主鍵)、count(字段)的區別

以下,基于 InnoDB。

含義區別

count() 是一個聚合函數,對于返回的結果集,會逐行判斷,若返回的不是 NULL,就會加 1,否則不加。

因此,count(*)count(主鍵 id)count(1) 都表示返回滿足條件的結果集的總行數;而 count(字段),則表示返回滿足條件的數據行里面,參數“字段”不為 NULL 的總個數。

性能區別

分析性能,考慮以下幾個原則:

1、server 層要什么就會返回什么;
2、InnoDB 只返回必要的值;
3、優化器只優化了 count(*)

對于 count(主鍵id),InnoDB 會遍歷全表,取每行的主鍵 id,返回給 server 層,server 層拿到數據后,進行判斷累加。

對于 count(1),InnoDB 仍遍歷全表,但是不取值,server 層對返回的每一行數據新增一個 1,然后進行判斷累加;

因此,count(1) 要更快些,因為無需取值。從引擎返回 id 會涉及到解析數據行,以及拷貝字段值的操作。

對于 count(字段)

1、如果這個“字段”是定義為 not null 的話,一行行地從記錄里面讀出這個字段,判斷不能為 null,按行累加;2、如果這個“字段”定義允許為 null,那么執行的時候,判斷到有可能是 null,還要把值取出來再判斷一下,不是 null 才累加。

但是 count(*) 是例外,并不會把全部字段取出來,而是專門做了優化,不取值。count(*) 肯定不是 null,按行累加。

結論:按照效率排序的話,count(字段)<count(主鍵 id)<count(1)≈count(*),所以我建議你,盡量使用 count(*)


你的關注是對我最大的鼓勵!

關注本公眾號,后臺回復「2018」即可獲取傳智播客 2018 最新 Python 和 Java 教程。

公眾號提供CSDN資源免費下載服務!


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

推薦閱讀更多精彩內容

  • 一、MySQL優化 MySQL優化從哪些方面入手: (1)存儲層(數據) 構建良好的數據結構。可以大大的提升我們S...
    寵辱不驚丶歲月靜好閱讀 2,454評論 1 8
  • 索引 數據庫中的查詢操作非常普遍,索引就是提升查找速度的一種手段 索引的類型 從數據結構角度分 1.B+索引:傳統...
    一凡呀閱讀 2,973評論 0 8
  • 轉 # https://www.cnblogs.com/easypass/archive/2010/12/ 08/...
    呂品?閱讀 9,753評論 0 44
  • count(*) 的實現方式 討論的是沒有過濾條件的 count(*)在不同的 MySQL 引擎中,count(*...
    胖達_4b7e閱讀 352評論 0 0
  • 細雨霏霏,黃昏的唐克鎮,寂寥無人。 劉叔拉我們到了“九曲”大酒店。酒店大堂和客房部很有些距離,冒雨拖了行李,摸索著...
    梅紫cym閱讀 518評論 0 1