公司來了一位架構師，看我用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)<count(1)≈count(*)
總結
基于MySQL的Innodb存儲引擎，統計表的總記錄數按照效率排序的話count(字段)<count(主鍵id)<count(1)≈count(*)
效率最高是count(*),并不是count(1)
所以建議盡量使用count()。
如果有面試官問你mysql中count(*)和count(1)哪個效率高？你就可以明確地告訴他，Innodb存儲引擎下效率最高是count(*)。
由于筆者知識水平有限,文中錯漏之處在所難免,如有不足之處，歡迎糾正，感謝。
