count(*)实现
首先要明确的是,在不同MySQL引擎中,count(*)有不同的实现。
- MyISAM引擎把一张表的总行数存在磁盘上,因此count(*)的时候可以直接返回这个数,效率很高
- 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(*)