MySQL计数优化探秘：COUNT(*)、COUNT(主键)与索引字段，谁是性能王者？

count(*)实现

        首先要明确的是，在不同MySQL引擎中，count(*)有不同的实现。

1. MyISAM引擎把一张表的总行数存在磁盘上，因此count(*)的时候可以直接返回这个数，效率很高
2. InnoDB引擎就麻烦了，执行count(*)的时候，需要把数据一行一行地从引擎里读出来，然后累计计数

        那InnoDB为什么不能和MyISAM一样，也把数字存起来呢？

        因为即使在同一时刻的多个查询，由于多版本并发控制(MVCC)的原因，InnoDB表应该返回多少行也是不确定的。这里用count(*)的例子来看一下。

        假设表 t 中现在有 10000 条记录，设计了三个用户并行的会话。

• 会话 A 先启动事务并查询一次表的总行数；
• 会话 B 启动事务，插入一行记录后，查询表的总行数；
• 会话 C 先启动一个单独的语句，插入一行记录后，查询表的总行数。

        最后时刻，三个会话A、B、C会同时查询表t的总行数，但拿到的结果却不同。

        这和InnoDB的事务设计有关，可重复读是默认的隔离级别，在代码上就是通过多版本并发控制，也就是MVCC实现的。每一行记录都要判断自己是否对会话可见，因此对于count(*)请求来说，InnoDB只好把数据一行行地读出来判断，可见的行才能用于计算这个查询的总行数。

        当然，MySQL在执行count(*)操作时还是做了优化的。

        InnoDB是索引组织表，主键索引树的叶子节点是数据，而普通索引树的叶子节点是主键值。所以普通索引树比主键索引树小很多。对于count(*)这样的操作，遍历哪个索引树得到的结果逻辑上都是一样的。MySQL优化器会找到最小的那棵树遍历。在保证逻辑正确的前提下，尽量减少扫描数据量，是数据库系统设计的通用法则之一。

不同count的用法

        count()是一个聚合函数，对于返回的结果集，一行行的判断，如果count函数返回值不是NULL，累计值就加1，否则不加，最后返回累计值。

        所以，count(*)、count(主键id)、count(1)都标识满足条件的结果集的总行数；而count(字段)，则表示返回满足条件的数据行里面，参数不为null的总行数。

        至于分析性能，有几个原则

• server层要什么就给什么
• InnoDB只给必要的值
• 现在的优化器只优化了count(*)的语义为取总行数，其他的优化并没有

        对于count(主键)来说，InnoDB会遍历整张表，把每一行的id值取出来，返回给server层。server层拿到id后，判断是不可能为空的，就按行累加。

        对于count(1)来说，InnoDB引擎遍历整张表，但不取值。server对于返回的每一行，放一个数字1进去，判断是不可能为空的，按行累加。

        单看这两个用法的差别的话，能对比出来，count(1)执行要比count(主键id)快。因为从引擎返回id会涉及到解析数据行，以及拷贝字段值的操作。

        对于count(字段)来说：

• 如果这个字段是定义为not null的话，一行行的从记录里读出这个字段，判断不能为null，按行累加；
• 如果这个字段允许为null，执行的时候，判断到可能是null，还要把值取出来在判断一下，不是null才累加

        但count(*)是个例外，并不会把全部字段取出来，而是专门做了优化，不取值。count(*)肯定不是null，按行累加。

        按照效率排序：count(字段) < count(主键id) < count(1) ≈ count(*)