Mysql性能優化:爲什麼count(*)這麼慢?

導讀

  • 在開發中一定會用到統計一張表的行數,比如一個交易系統,老闆會讓你每天生成一個報表,這些統計信息少不了sql中的count函數。

  • 但是隨着記錄越來越多,查詢的速度會越來越慢,爲什麼會這樣呢?Mysql內部到底是怎麼處理的?

  • 今天這篇文章將從Mysql內部對於count函數是怎樣處理的來展開詳細的講述。

count的實現方式

  • 在Mysql中的不同的存儲引擎對count函數有不同的實現方式。

  • MyISAM引擎把一個表的總行數存在了磁盤上,因此執行count(*)的時候會直接返回這個數,效率很高(沒有where查詢條件)。

  • InnoDB引擎並沒有直接將總數存在磁盤上,在執行count(*)函數的時候需要一行一行的將數據讀出來,然後累計總數。

爲什麼InnoDB不將總數存起來?

  • 說到InnoDB相信讀者總會想到其支持事務的特性,事務具有隔離性,如果將總數存起來,怎麼保證各個事務之間的總數的一致性呢?不明白的看下圖:

  • 事務A事務B中的count(*)的執行結果是不同的,因此InnoDB引擎在每個事務中返回多少行是不確定的,只能一行一行的讀出來用來判斷總數。

如何提升count效率

  • InnoDB對於如何提升count(*)的查詢效率,網上有多種解決辦法,這裏主要介紹三種,並分析可行性。

show table status

  • show table status這個命令能夠很快的查詢出數據庫中每個表的行數,但是真的能夠替代count(*)嗎?

  • 答案是不能。原因很簡單,這個命令統計出來的值是一個「估值」,因此是不準確的,官方文檔說誤差大概在40%-50%

  • 因此這種方法直接pass,不準確還用它幹嘛。

緩存系統存儲總數

  • 這種方法也是最容易想到的,增加一行就+1,刪除一行就-1,並且緩存系統讀取也是很快,既簡單又方便的爲什麼不用?

  • 緩存系統和Mysql是兩個系統,比如redisMysql這兩個是典型的比較。兩個系統最難的就是在高併發下無法保證數據的一致性。通過以下兩圖我們來理解一下:

  • 通過上面兩張圖,無論是redis計數+1還是insert into user先執行,最終都會導致數據在邏輯上的不一致。第一張圖會出現redis計數少了,第二張圖雖然計數正確了但是並沒有查詢出插入的那一行數據。

  • 在併發系統裏面,我們是無法精確控制不同線程的執行時刻的,因爲存在圖中的這種操作序列,所以,我們說即使Redis正常工作,這個計數值還是邏輯上不精確的。

在數據庫保存計數

  • 通過緩存系統保存的分析得知了使用緩存無法保證數據在邏輯上的一致性,因此我們想到了直接使用數據庫來保存,有了「事務」的支持,也就保證了數據的一致性了。

  • 如何使用呢?很簡單,直接將計數保存在一張表中(table_name,total)

  • 至於執行的邏輯只需要將緩存系統中redis計數+1改成total字段+1即可,如下圖:

  • 由於在同一個事務中,保證了數據在邏輯上的一致性。

不同count的用法

  • count()是一個聚合函數,對於返回的結果集,一行行地判斷,如果count函數的參數不是NULL,累計值就加1,否則不加。最後返回累計值。

  • count的用法有多種,分別是count(*)count(字段)count(1)count(主鍵id)。那麼多種用法,到底有什麼差別呢?當然,「前提是沒有where條件語句」

  • count(id):InnoDB引擎會遍歷整張表,把每一行的id值都取出來,返回給server層。server層拿到id後,判斷是不可能爲空的,就按行累加。

  • count(1):InnoDB引擎遍歷整張表,但不取值。server層對於返回的每一行,放一個數字1進去,判斷是不可能爲空的,按行累加。

  • count(字段)

    • 如果這個“字段”是定義爲not null的話,一行行地從記錄裏面讀出這個字段,判斷不能爲null,按行累加;

    • 如果這個字段定義允許爲null,那麼執行的時候,判斷到有可能是null,還要把值取出來再判斷一下,不是null才累加。

  • count(*):不會把全部字段取出來,而是專門做了優化,不取值。count(*)肯定不是null,按行累加。

  • 所以結論很簡單:「按照效率排序的話,count(字段)<count(主鍵id)<count(1)count(*),所以建議讀者,儘量使用count(*)。」

  • 「注意」:這裏肯定有人會問,count(id)不是走的索引嗎,爲什麼查詢效率和其他的差不多呢?陳某在這裏解釋一下,雖然走的索引,但是還是要一行一行的掃描才能統計出來總數。

總結

  • MyISAM表雖然count(*)很快,但是不支持事務;

  • show table status命令雖然返回很快,但是不準確;

  • InnoDB直接count(*)會遍歷全表(沒有where條件),雖然結果準確,但會導致性能問題。

  • 緩存系統的存儲計數雖然簡單效率高,但是無法保證數據的一致性。

  • 數據庫保存計數很簡單,也能保證數據的一致性,建議使用。

  • 「思考題,讀者留言區討論」:在系統高併發的情況下,使用數據庫保存計數,是先更新計數+1,還是先插入數據。即是先update total+=1還是先insert into

留言討論區

往期推薦

一條SQL查詢語句是如何執行的?Mysql性能優化:爲什麼要用覆蓋索引?Mysql性能優化:什麼是索引下推?Mysql中的三類鎖,你知道嗎?Mysql性能優化:如何給字符串加索引?

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章