建站
咨詢
售后
建站咨詢
新聞中心
公司來了一位架構師，看我用count(*)統(tǒng)計數(shù)據(jù)總數(shù)。
站在用戶的角度思考問題，與客戶深入溝通，找到天水網(wǎng)站設計與天水網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設計與互聯(lián)網(wǎng)技術結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：網(wǎng)站制作、網(wǎng)站設計、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、國際域名空間、網(wǎng)頁空間、企業(yè)郵箱。業(yè)務覆蓋天水地區(qū)。
對我說，你怎么用count(*)統(tǒng)計數(shù)據(jù)，count(*)太慢了，要是把數(shù)據(jù)庫搞垮了怎么搞，用count(1)。嚇得我趕緊換成了count(1)。
count(1) 性能就比count(*)高嗎?
記得有次面試時，面試官也問我類似這樣的問題，mysql統(tǒng)計數(shù)據(jù)總數(shù)count(*)和count(1)哪個效率高?
今天來聊一聊count(1)和count(*)效率問題。
不同存儲引擎的性能不一樣
我們不知道，Mysql常見的存儲引擎有兩種，MyISAM和Innodb，在這兩種存儲引擎下，MySQL對于使用count(*)返回結(jié)果的流程是不一樣的。
- 在MyISAM引擎中，每張表的總行數(shù)是存儲在磁盤上，所以當執(zhí)行count(*)時，是直接從磁盤拿到這個值返回，能夠快速返回。但要是在后面加了where查詢條件時，統(tǒng)計總數(shù)也不是像想象中那么快了。
- 在Innodb引擎中，執(zhí)行count(*)，需要將數(shù)據(jù)一行一行地讀，再統(tǒng)計總數(shù)。
看到這里，不知道你有沒有這樣的疑問：
- 為什么Innodb引擎不像MyISAM引擎一樣把表總記錄存儲起來呢?
這個問題問得好，回答這個問題前，我們先了解下MVCC。
什么是MVCC
全稱：Multi-Version Concurrency Control 即多版本并發(fā)控制，MVCC 是一種并發(fā)控制的方法，一般在數(shù)據(jù)庫管理系統(tǒng)中，實現(xiàn)對數(shù)據(jù)庫的并發(fā)訪問;在編程語言中實現(xiàn)事務內(nèi)存。
MVCC 在 MySQL InnoDB 中的實現(xiàn)主要是為了提高數(shù)據(jù)庫并發(fā)性能，用更好的方式去處理讀-寫沖突，做到即使有讀寫沖突時，也能做到不加鎖，非阻塞并發(fā)讀。
就是因為要實現(xiàn)多版本并發(fā)控制，所以才導致Innodb不能直接存儲表總記錄數(shù)。
因為每個事務獲取到的一致性視圖都是不一樣的，所以返回的數(shù)據(jù)總記錄也是不一致的。
舉個例子說明下：
假如有一張用戶表tb_user, 有三處正在查詢用戶的總數(shù)。
select count(*) from tb_user
這時候每次查到的用戶數(shù)總數(shù)可能不太一樣。
這是因為每個用戶會根據(jù)read view存儲的數(shù)據(jù)來判斷哪些數(shù)據(jù)是自己可見的，哪些是不可見的。
read view
當執(zhí)行SQL語句查詢時會產(chǎn)生一致性視圖，即read-view，它是由查詢的那一刻所有未提交事務ID組成的數(shù)組，和已經(jīng)創(chuàng)建的最大事務ID組成的。
在這個數(shù)組中最小的事務ID被稱之為min_id，最大事務ID被稱之為max_id，而查詢的數(shù)據(jù)結(jié)果就是根據(jù)read-view做對比從而得到快照。
于是就產(chǎn)生了以下的對比規(guī)則，這個規(guī)則就是使用當前的記錄的trx_id跟read-view進行對比，規(guī)則如下：
- 如果落在trx_id
- 如果落在trx_id>max_id，表示該版本是由將來啟動的事務生成的，是不可見的
- 如果落在trx_id 在min_id 和max_id 中間(min_id<=trx_id<=max_id)時
要是row的trx_id在數(shù)組中，表示該版本是由還沒提交的事務生成的，不可見，但是當前自己的事務是可見的;要是row的trx_id不在數(shù)組中，表明是提交的事務生成了該版本，是可見的。
讀到這，相信你已經(jīng)知道Innodb引擎為什么不像MyISAM引擎一樣把表總記錄存儲起來了吧。因為 InnoDB 支持事務，MyISAM不支持事務。
在執(zhí)行count(*)操作的時候還是做了優(yōu)化的。
mysql對count(*)做了優(yōu)化
InnoDB是索引組織表，主鍵索引樹的葉子節(jié)點是數(shù)據(jù)，而普通索引樹的葉子節(jié)點是主鍵值。所以，普通索引樹比主鍵索引樹小很多。對于count(*)這樣的操作，遍歷哪個索引樹得到的結(jié)果邏輯上都是一樣的。因此，MySQL優(yōu)化器會找到最小的那棵樹來遍歷。
如果你使用過show table status 命令的話，就會發(fā)現(xiàn)這個命令的輸出結(jié)果里面也有一個rows值用于顯示這個表當前有多少行。
那么是不是這個rows值就能代替count(*)了嗎?
其實不能，rows這個是從從采樣估算得來的，因此它也是不是準確。不準確到什么程度，官方文檔說是在40%到50%。所以show table status命令顯示的行數(shù)rows是不能直接使用。
基于MySQL的Innodb存儲引擎，統(tǒng)計表的總記錄數(shù)下面這4種做法，哪種效率最高?
實踐案例，準備了一張有 500W多條數(shù)據(jù)的表，表結(jié)構如下：
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
可以看到，這張表有一個主鍵索引，用不同方式來查詢該表用戶記錄總數(shù)。
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層對返回的每一行，放一個數(shù)字1進去，判斷是不可能為空的，按行累加。
count(字段)
用select count(user_name) from tb_user 耗時1.436s
分為兩種情況，字段定義為not null和null
- 為not null時：逐行從記錄里面讀出這個字段，判斷不能為null，累加
- 為 null時：執(zhí)行時，判斷到有可能是null，還要把值取出來再判斷一下，不是null才累加
count(*)
用select count(*) from tb_user 耗時0.739s
需要注意的是，并不是帶了*就把所有值取出來，而是mysql做了專門的優(yōu)化，count(*)肯定不是null，按行累加。
從上面的執(zhí)行結(jié)果，得知count(字段) 基于MySQL的Innodb存儲引擎，統(tǒng)計表的總記錄數(shù)按照效率排序的話count(字段) 效率最高是count(*),并不是count(1) 所以建議盡量使用count()。 如果有面試官問你mysql中count(*)和count(1)哪個效率高?你就可以明確地告訴他，Innodb存儲引擎下效率最高是count(*)。總結(jié)
分享文章：面試官：MySQL中Count(*)和Count(1)哪個效率高？
標題來源：http://www.dlmjj.cn/article/ccssoci.html
