MySQL實戰 | 14 爲什麼count(*)越來越慢? count(*) 的實現方式 count(*)、count(1)、count(主鍵)、count(字段)的區別

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

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

count(*) 的實現方式

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

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

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

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

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

而 InnoDB 就不一樣了。

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

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

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

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

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資源免費下載服務!


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章