MySQL的優化器對于count(*）的處理方式是什么

今天就跟大家聊聊有關MySQL的優化器對于count(*）的處理方式是什么，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

   最近看了很多阿里同學的MySQL文章，阿里內核同學的文章一言不合就上代碼，不光讓我們看到了結果，還能有代碼可讀，如果碰到了類似的問題，這樣的解讀確實是很難得的。

   今天做了一個小的測試，發現MySQL 5.7中對于count(*)的處理好像有點霸道，沒想象中那么好。

   為了對比，我找了一套5.6的環境。

總體而言5.6的環境中對于count(*)的處理可塑性很強，很隨和，你讓我怎么查我就怎么查。初始數據為100萬。

+----------+
| count(*) |
+----------+
|  1000000 |
+----------+

建表的語句如下：

>show create table test\G
*************************** 1. row ***************************
       Table: test
Create Table: CREATE TABLE `test` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` int(11) DEFAULT NULL,
  `b` int(11) DEFAULT NULL,
  `c` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `mrrx` (`a`,`b`),
  KEY `xx` (`c`)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)一直以來MySQL中count(*)的用法都是不被提倡，或者說是惡名遠揚，這一點讓很多學習Oracle的同學很不理解，其實他們是身在福中不知福。

這樣的一個count(*)的查詢，在5.6中的效果是這樣的，估算的時候默認是走了索引xx

>explain select count(*) from test\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: test
         type: index
possible_keys: NULL
          key: xx
      key_len: 5
          ref: NULL
         rows: 998396
        Extra: Using index
1 row in set (0.01 sec)   
如果我們強制走mrrx索引，優化器說也行，于是就走了mrrx的索引，估算的數據情況和上面有一些小的差別。
>explain select count(*) from test force index(mrrx)\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: test
         type: index
possible_keys: NULL
          key: mrrx
      key_len: 10
          ref: NULL
         rows: 947698
        Extra: Using index
1 row in set (0.00 sec)或者我們顯式指定就要xx索引了，優化器說好，然后估算得到的行數和第一個差別很小。
>explain select count(*) from test force index(xx)\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: test
         type: index
possible_keys: NULL
          key: xx
      key_len: 5
          ref: NULL
         rows: 947698
        Extra: Using index
1 row in set (0.00 sec)如果換一種姿勢，如果指定索引列c,指定一個條件，再來看看，就會看到前后的結果差別就很大了。
>explain select count(*) from test where c > 0\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: test
         type: range
possible_keys: xx
          key: xx
      key_len: 5
          ref: NULL
         rows: 473849
        Extra: Using where; Using index
1 row in set (0.00 sec)這么看來，5.6里面的一個硬傷還是對于統計信息這塊的評估差別較大，沒有了統計信息還是有很大的局限性，不過優化器還是很隨和的。

我們看看5.7的表現

同樣的語句和數據量，在5.7中明顯做了過濾處理，

> explain select count(*) from test\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: NULL
   partitions: NULL
         type: NULL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: NULL
     filtered: NULL
        Extra: Select tables optimized away
1 row in set, 1 warning (0.02 sec)

這表示在優化器階段已經被優化了。

而接下來同樣的語句也都是同樣的處理方式。

> explain select count(*) from test force index(mrrx)\G
> explain select count(*) from test force index(xx)\G
        Extra: Select tables optimized away

而如果我們還是像之前一樣給定索引列c一個過濾條件，優化器就一下子變得溫和起來。很明顯這個執行的效果要好很多。

> explain select count(*) from test where c > 0\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: test
   partitions: NULL
         type: range
possible_keys: xx
          key: xx
      key_len: 5
          ref: NULL
         rows: 498949
     filtered: 100.00
        Extra: Using where; Using index
1 row in set, 1 warning (0.02 sec)

從某種程度來說，5.7這樣的處理也算是一種變相的退步啦。

看完上述內容，你們對MySQL的優化器對于count(*）的處理方式是什么有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。