業(yè)務(wù)發(fā)展初期，為了功能的快速實(shí)現(xiàn)，遇到統(tǒng)計(jì)行數(shù)的需求時(shí)，我們一般都是簡(jiǎn)單的使用count函數(shù)搞定。

但是有的小伙伴可能慢慢會(huì)發(fā)現(xiàn)，隨著表中的數(shù)據(jù)越來越多，count統(tǒng)計(jì)數(shù)據(jù)的速度越來越慢，耗時(shí)也越來越長(zhǎng)了。

今天帶大家了解一下，為什么MySQL的count函數(shù)會(huì)越來越慢，count函數(shù)的實(shí)現(xiàn)邏輯是什么，以及如何解決大數(shù)據(jù)量下的統(tǒng)計(jì)需求？

count函數(shù)的執(zhí)行邏輯

我們知道，MySQL分為Server層和引擎層，引擎大家基本使用的都是InnoDB，這里就不再重復(fù)強(qiáng)調(diào)了。

那對(duì)于下面這樣一條sql，MySQL是如何執(zhí)行的呢？

select count(*) from t；

由于我們并沒有使用where條件，那么對(duì)于MySQL來說，從聚簇索引或二級(jí)索引來統(tǒng)計(jì)數(shù)據(jù)都是可以的。

并且普通的二級(jí)索引只存儲(chǔ)了索引鍵以及主鍵，所以相對(duì)于聚簇索引來說，二級(jí)索引樹會(huì)更矮更胖，MySQL會(huì)優(yōu)先使用二級(jí)索引，以達(dá)到減少IO提升性能的目的。

MySQL執(zhí)行count的邏輯如下：

1. Server通過執(zhí)行器調(diào)用InnoDB的查詢接口，嘗試獲取第一條數(shù)據(jù)。
2. InnoDB引擎在二級(jí)索引上找到第一條記錄，并返回給Server層。

注意：這里雖然使用count(*)查詢，但是并不需要到聚簇索引上回表，因?yàn)樽罱K的目的是統(tǒng)計(jì)聚合后的行數(shù)，回表并沒有什么意義。InnoDB會(huì)給Server返回一個(gè)常數(shù)0，表示這一行記錄有效。

3.Server層收到常數(shù)0，并判斷常數(shù)0不是null，認(rèn)為返回值有效，會(huì)將統(tǒng)計(jì)值+1。

4.Server通過執(zhí)行器調(diào)用InnoDB查詢接口，獲取下一條記錄。

5.InnoDB順著二級(jí)索引找下一條記錄，繼續(xù)返回常數(shù)0。

6.重復(fù)步驟3，4，5，直到將整棵二級(jí)索引樹掃描完，最終將統(tǒng)計(jì)的結(jié)果發(fā)給客戶端。

大家可以看到，MySQL在執(zhí)行count函數(shù)時(shí)，會(huì)遍歷某一個(gè)索引樹，查詢樹上所有的記錄進(jìn)行累加統(tǒng)計(jì)。

隨著表中的記錄越來越多，索引樹也會(huì)越來越高，越來越胖。

那么整個(gè)統(tǒng)計(jì)過程也會(huì)越來越耗時(shí)。

這就是為什么count函數(shù)會(huì)越來越慢的原因。

大數(shù)據(jù)量下的如何快速統(tǒng)計(jì)行數(shù)

這里有兩個(gè)考慮的因素：絕對(duì)精準(zhǔn)和允許誤差。

如果在極大數(shù)據(jù)量下，允許有誤差產(chǎn)生。那么我們可以提前維護(hù)一個(gè)變量count，通過記錄表中的增刪改操作，對(duì)這個(gè)變量做相應(yīng)的加減。這樣在獲取行數(shù)時(shí)，只需要查詢這個(gè)變量就可以快速獲取結(jié)果了。

如果要求絕對(duì)精準(zhǔn)，并且對(duì)性能要求也不太高，那么就繼續(xù)使用count函數(shù)吧。不要覺得這個(gè)方法low，能滿足業(yè)務(wù)的方法都是好方法。

如果對(duì)性能要求也很高，那么OLAP數(shù)據(jù)庫可能會(huì)是一個(gè)好選擇。

不同count函數(shù)的性能差異

經(jīng)常有小伙伴糾結(jié)count(*)、count(1)、count(主鍵)、count(非索引列)的性能差異。

通過上文我們可以知道，使用count(*)時(shí)，InnoDB引擎返回的是常數(shù)0，那么自然count(1)返回的也是常數(shù)，這兩個(gè)性能可以看做是一致的。

對(duì)于count(主鍵)，由于二級(jí)索引樹上直接保存著主鍵id，所以不會(huì)有回表的操作。由于InnoDB返回到Server的是主鍵id，而如果主鍵id又恰巧比較大，比如是一個(gè)較長(zhǎng)的字符串時(shí)，性能會(huì)產(chǎn)生稍微的下滑。

對(duì)于count(非索引列)，由于需要不停的回表，這種方式性能相對(duì)是非常差的，也是不推薦的一種做法。

按性能排序：count(*) ≈ count(1) > count(主鍵) > count(非索引列)。