14 count(*)

14 count(*)

count(*)实现方式

首先要声明，在不同的mysql引擎中，count(*)有不同的实现方式。

--myisam引擎把一个表的总行数存在了磁盘，因此执行count(*)的时候会直接返回这个树，效率很高。

--而innodb引擎就麻烦了，执行count(*)的时候，需要把数据一行一行的从引擎里面读出来，然后累计计数。

这里需要注意的是，这篇文章里讨论的是没有过滤条件的count，如果加了where条件的话，myisam表也不是能返回这么快的。

为什么innodb不跟myisam一样，也把数字存起来呢？

这是因为即使是在同一时刻的多个查询，由于多版本并发控制MVCC的原因，innodb表”应该返回多少行”也是不确定。这里，举一个例子

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

--会话a先启动一个事务并查询一次表的总数

--会话b启动事务，插入一行记录后，查询表的总数

--会话c先启动一个单独的语句，插入一行，查询表的总行数。

Session a	Session b	Session c
begin; select count(*) from t;
		insert into t(插入一行)
	begin; insert into t(插入一行)
select count(*) from t; 返回10000	select count(*) from t; 返回10002	select count(*) from t; 返回10001

你会看到，在最后一个时刻，三个会话a、b、c会同时查询表t的总数，但拿到的结果却不一样。

对于innodb来说，count(*)请求，innodb会把数据一行一行地读出来依次判断，可见的行才能够被统计。

Innodb是索引组织表，主键索引树的叶子节点是数据，而普通索引树的叶子节点是主键值，所以，普通索引树比主键索引树小很多，对于count(*)这样的操作，

遍历那个索引树得到的结果逻辑上都是一样的，因此，mysql优化器会找最小的那棵树来遍历，在保证逻辑正确的前提下，尽量减少扫描的数据量，是数据库系统设计的通用法则之一。

用过show table status的话，发现这个命令输出结果里面也有table_rows用于显示这个表有多少行，这个命令执行挺快的，但是能用table_rows代替count(*)吗？

索引统计的值是通过采样估计计算的，实际上，table_rows就是从这个采样估算得来的，所以，table_rows不能直接使用。

--myisam表虽然count(*)很快，但不支持事务

--show table status命令返回虽然快，但是不准确

--innodb表直接count(*)会遍历全表，虽然结果准确，但会导致性能问题。

用缓存系统保存计数

对于更新频繁的库来说，你可能第一时间会想到，用缓存系统来支持计数

你可以用一个redis服务来保存这个表的总行数，这个表每被插入一行redis计数就加1，每被删除一行redis计数就减1，这种方式下，读和更新操作都很快，但是，这种方式会存在缓存系统可能会丢失更新。

Redis的数据不能永远留在内存里，所以会找个地方把这个值持久化的存储起来，即使这样，仍然可能丢失更新，redis异常重启，到数据库单独执行一次count(*)来保证计数的正确性。

在并发系统里面，无法精确控制不同线程的执行时刻的，计数在逻辑上可能不精确。

在数据库保存计数

如果把计数直接放到数据库里单独的一张计数表中，又会怎么样呢？

首先，这解决了崩溃丢失的问题，innodb是支持崩溃恢复不丢失数据的。

然后，看能不能解决计数不精确的问题

利用事务特性来保证逻辑上的一致

begin;

计数表数值加1

插入一行数据

commit;

不同的count用法

在select count(?) from t,这样的查询里面count(*),count(pk id),count(col),count(1)等不同用法的性能有那些差别

基于innodb引擎，count()语义是一个聚合函数，对于返回的结果集，一行行的判断，如果count函数的参数不是null，累计值加1，否则不加，最后返回累计值。

所以，count(*),count(pk id),count(1)都表示返回满足条件的结果集的总行数，而count(col)则表示返回满足条件的数据行里面，参数字段不为null的总个数。

至于分析性能差别的时候，可以记住这几个原则

--server层要什么就给什么

--innodb只给必要的值

--现在的优化器只优化了count(*)的语义为取行数，其他的优化并没有做

对于count(pk id)来说，innodb引擎会遍历整张表，把每一行的id值都取出来，返回给server层，server层拿到id后，判断是不可能为null的，就按行累加

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

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

对于count(col)来说

--如果这个字段定义为not null，一行行地从记录里面读出这个字段，判断不能为null，按行累加

--如果这个字段定义允许为null，那么执行的时候，判断到有可能是null，还要把值取出来再判断一下，不是null才累加

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

所以结论是：按照效率排序的话，count(col)<count(pk id)<count(1)<count(*),所以，建议尽量用count(*).