公司來了一位架構師，看我用count(*)統計數據總數。

對我說，你怎么用count(*)統計數據，count(*)太慢了，要是把數據庫搞垮了怎么搞，用count(1)。嚇得我趕緊換成了count(1)。

count(1) 性能就比count(*)高嗎?

記得有次面試時，面試官也問我類似這樣的問題，mysql統計數據總數count(*)和count(1)哪個效率高?

今天來聊一聊count(1)和count(*)效率問題。

不同存儲引擎的性能不一樣

我們不知道，Mysql常見的存儲引擎有兩種，MyISAM和Innodb，在這兩種存儲引擎下，MySQL對于使用count(*)返回結果的流程是不一樣的。

• 在MyISAM引擎中，每張表的總行數是存儲在磁盤上，所以當執行count(*)時，是直接從磁盤拿到這個值返回，能夠快速返回。但要是在后面加了where查詢條件時，統計總數也不是像想象中那么快了。
• 在Innodb引擎中，執行count(*)，需要將數據一行一行地讀，再統計總數。

看到這里，不知道你有沒有這樣的疑問：

• 為什么Innodb引擎不像MyISAM引擎一樣把表總記錄存儲起來呢?

這個問題問得好，回答這個問題前，我們先了解下MVCC。

什么是MVCC

全稱：Multi-Version Concurrency Control 即多版本并發控制，MVCC 是一種并發控制的方法，一般在數據庫管理系統中，實現對數據庫的并發訪問;在編程語言中實現事務內存。

MVCC 在 MySQL InnoDB 中的實現主要是為了提高數據庫并發性能，用更好的方式去處理讀-寫沖突，做到即使有讀寫沖突時，也能做到不加鎖，非阻塞并發讀。

就是因為要實現多版本并發控制，所以才導致Innodb不能直接存儲表總記錄數。

因為每個事務獲取到的一致性視圖都是不一樣的，所以返回的數據總記錄也是不一致的。

舉個例子說明下：

假如有一張用戶表tb_user, 有三處正在查詢用戶的總數。

select count(*) from tb_user

這時候每次查到的用戶數總數可能不太一樣。

這是因為每個用戶會根據read view存儲的數據來判斷哪些數據是自己可見的，哪些是不可見的。

read view

當執行SQL語句查詢時會產生一致性視圖，即read-view，它是由查詢的那一刻所有未提交事務ID組成的數組，和已經創建的最大事務ID組成的。

在這個數組中最小的事務ID被稱之為min_id，最大事務ID被稱之為max_id，而查詢的數據結果就是根據read-view做對比從而得到快照。

于是就產生了以下的對比規則，這個規則就是使用當前的記錄的trx_id跟read-view進行對比，規則如下：

• 如果落在trx_id<min_id，表示該版本是已經提交的事務生成的，由于事務已經提交所以數據是可見的
• 如果落在trx_id>max_id，表示該版本是由將來啟動的事務生成的，是不可見的
• 如果落在trx_id 在min_id 和max_id 中間(min_id<=trx_id<=max_id)時

要是row的trx_id在數組中，表示該版本是由還沒提交的事務生成的，不可見，但是當前自己的事務是可見的;要是row的trx_id不在數組中，表明是提交的事務生成了該版本，是可見的。

讀到這，相信你已經知道Innodb引擎為什么不像MyISAM引擎一樣把表總記錄存儲起來了吧。因為 InnoDB 支持事務，MyISAM不支持事務。

在執行count(*)操作的時候還是做了優化的。

mysql對count(*)做了優化

InnoDB是索引組織表，主鍵索引樹的葉子節點是數據，而普通索引樹的葉子節點是主鍵值。所以，普通索引樹比主鍵索引樹小很多。對于count(*)這樣的操作，遍歷哪個索引樹得到的結果邏輯上都是一樣的。因此，MySQL優化器會找到最小的那棵樹來遍歷。

如果你使用過show table status 命令的話，就會發現這個命令的輸出結果里面也有一個rows值用于顯示這個表當前有多少行。

那么是不是這個rows值就能代替count(*)了嗎?

其實不能，rows這個是從從采樣估算得來的，因此它也是不是準確。不準確到什么程度，官方文檔說是在40%到50%。所以show table status命令顯示的行數rows是不能直接使用。

基于MySQL的Innodb存儲引擎，統計表的總記錄數下面這4種做法，哪種效率最高?

實踐案例，準備了一張有 500W多條數據的表，表結構如下：

CREATE TABLE `tb_user` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`user_id` int(11) DEFAULT NULL ,
`user_name` varchar(100) DEFAULT NULL ,
PRIMARY KEY (`id`) USING BTREE,
UNIQUE KEY `userId` (`user_id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4

可以看到，這張表有一個主鍵索引，用不同方式來查詢該表用戶記錄總數。

count(主鍵id)

用select count(*) from tb_user 耗時0.739s

InnoDB引擎會遍歷整張表，把每一行的id值都取出來，返回給server層。server層拿到id后，判斷是不可能為空的，就按行累加。

count(1)

用select count(1) from tb_user 耗時0.753s

同樣遍歷整張表，但不取值，server層對返回的每一行，放一個數字1進去，判斷是不可能為空的，按行累加。

count(字段)

用select count(user_name) from tb_user 耗時1.436s

分為兩種情況，字段定義為not null和null

• 為not null時：逐行從記錄里面讀出這個字段，判斷不能為null，累加
• 為 null時：執行時，判斷到有可能是null，還要把值取出來再判斷一下，不是null才累加

count(*)

用select count(*) from tb_user 耗時0.739s

需要注意的是，并不是帶了*就把所有值取出來，而是mysql做了專門的優化，count(*)肯定不是null，按行累加。

從上面的執行結果，得知count(字段)<count(主鍵id)<count1≈count(*)

總結

基于MySQL的Innodb存儲引擎，統計表的總記錄數按照效率排序的話count(字段)<count(主鍵id)<count1≈count(*)

效率最高是count(*),并不是count(1)

所以建議盡量使用count()。

如果有面試官問你mysql中count(*)和count(1)哪個效率高?你就可以明確地告訴他，Innodb存儲引擎下效率最高是count(*)。