MySQL的优化器对于count(*的处理方式是什么

今天，我们来谈谈MySQL优化器如何处理计数(*)。很多人可能不太了解。为了让大家更好的了解，边肖为大家总结了以下内容。希望大家能从这篇文章中有所收获。

最近看了很多阿里同学的MySQL文章，阿里Kernel同学的文章一字不漏的加载到代码中，不仅让我们看到了结果，也让代码可读性更强。如果我们遇到类似的问题，这样的解读真的很少见。

今天做了一个小测试，发现MySQL 5.7对count(*)的处理好像有点霸道，没有我想象的那么好。

为了比较，我找到了一个5.6环境。

一般来说，在5.6的环境下对count(*)的处理是很有可塑性的，也很随和，你要我怎么做我就怎么做。最初的数据是100万。

-

|计数(*) |

-

| 1000000 |

-

构建表的语句如下：

显示创建表测试\G

*************************** 1.行**************************

表：测试

CREATE TABLE : CREATE TABLE ` test `(

` id` int(11)不为空自动增量，

` a` int(11) DEFAULT NULL，

` b` int(11) DEFAULT NULL，

` c` int(11) DEFAULT NULL，

主键(` id `),

KEY `mrrx` (`a `，` b `),

KEY `xx` (`c `)

)ENGINE=InnoDB AUTO _ INCREMENT=1000001 DEFAULT CHARSET=ut F8

集内1行(0.00秒)MySQL中count(*)的用法一直不被提倡，或者说臭名昭著，这让很多学习Oracle的同学非常困惑。事实上，他们不知道什么时候被祝福。

在5.6中，这样的count(*)查询具有这样的效果，即在估计时默认采用索引xx。

解释从测试中选择计数(*)\ G

*************************** 1.行**************************

id: 1

select_type: SIMPLE

表：测试

type:索引

可能的_ keys:空

key: xx

key_len: 5

ref:空

行： 998396

Extra:使用索引

1行一组(0.01秒)

如果我们强制mrrx索引，优化器说没问题，所以我们取了mrrx索引，估计的数据和上面略有不同。

解释从测试力指数(mrrx)中选择计数(*)\ G

*************************** 1.行**************************

id: 1

select_type: SIMPLE

表：测试

type:索引

可能_ 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(*）的处理方式是什么有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注行业资讯频道，感谢大家的支持。