業務發展初期，為了功能的快速實現，遇到統計行數的需求時，我們一般都是簡單的使用count函數搞定。

但是有的小伙伴可能慢慢會發現，隨著表中的數據越來越多，count統計數據的速度越來越慢，耗時也越來越長了。

今天帶大家了解一下，為什么MySQL的count函數會越來越慢，count函數的實現邏輯是什么，以及如何解決大數據量下的統計需求？

count函數的執行邏輯

我們知道，MySQL分為Server層和引擎層，引擎大家基本使用的都是InnoDB，這里就不再重復強調了。

那對于下面這樣一條sql，MySQL是如何執行的呢？

select count(*) from t；

由于我們并沒有使用where條件，那么對于MySQL來說，從聚簇索引或二級索引來統計數據都是可以的。

并且普通的二級索引只存儲了索引鍵以及主鍵，所以相對于聚簇索引來說，二級索引樹會更矮更胖，MySQL會優先使用二級索引，以達到減少IO提升性能的目的。

MySQL執行count的邏輯如下：

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

注意：這里雖然使用count(*)查詢，但是并不需要到聚簇索引上回表，因為最終的目的是統計聚合后的行數，回表并沒有什么意義。InnoDB會給Server返回一個常數0，表示這一行記錄有效。

3.Server層收到常數0，并判斷常數0不是null，認為返回值有效，會將統計值+1。

4.Server通過執行器調用InnoDB查詢接口，獲取下一條記錄。

5.InnoDB順著二級索引找下一條記錄，繼續返回常數0。

6.重復步驟3，4，5，直到將整棵二級索引樹掃描完，最終將統計的結果發給客戶端。

大家可以看到，MySQL在執行count函數時，會遍歷某一個索引樹，查詢樹上所有的記錄進行累加統計。

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

那么整個統計過程也會越來越耗時。

這就是為什么count函數會越來越慢的原因。

大數據量下的如何快速統計行數

這里有兩個考慮的因素：絕對精準和允許誤差。

如果在極大數據量下，允許有誤差產生。那么我們可以提前維護一個變量count，通過記錄表中的增刪改操作，對這個變量做相應的加減。這樣在獲取行數時，只需要查詢這個變量就可以快速獲取結果了。

如果要求絕對精準，并且對性能要求也不太高，那么就繼續使用count函數吧。不要覺得這個方法low，能滿足業務的方法都是好方法。

如果對性能要求也很高，那么OLAP數據庫可能會是一個好選擇。

不同count函數的性能差異

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

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

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

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

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