MYSQL-45讲之count(*)这么慢，该怎么办？

count(*)的实现方式

在不同的mysql引擎中，count(*有不同的实现方式)，MVCC多版本并发控制也有不同的实现方式。

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

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

这里需要注意的是，我们所讨论的是没有过滤条件的count(*)，如果见了where条件的话， MyISAM 表也是不能返回得这么快的。

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

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

show table status 命令显示的TABLE_ROWS行数是通过采样估算来的，用于索引统计基数的使用。

总结：

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

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

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

InnoDB如何统计记录总数？

在数据库保存计数

如果用缓存系统保存计数有丢失数据（redis异常重启）和计数不精确（两个系统不支持分布式事务）的问题。那么如果我们把这个计数直接放到数据库里单独的一张计数表中，这解决了崩溃丢失的问题，InnoDB是支撑崩溃恢复不丢数据的。

至于计数不准确的问题，完全可以交给事物解决。从并发系统性能的角度考虑，在这个事务序列里，应该先更新计数表，最后再插入操作记录；这样可以最大限度减少业务表写锁的持有时间，从而提高性能。

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

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

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

1.serve层要什么就给什么；

2.InnoDB只给必要的值；

3.现在的优化器只优化了count(*)的语义为‘取行数’，其他参数并没有做处理。

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

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

这两个用法比较，count(1)执行的要比count(主键id)快。因为从引擎返回id，InnoDB引擎层会涉及到解析数据行，以及拷贝字段值的操作。

对于count(字段)来说：

1.如果这个字段是定义为not null的话，一行行地从记录里面读出这个字段，判断不能为null,按行累加；

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

也就是前面第一条原则，server层要什么字段，InnoDB就返回什么字段。

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

按照执行效率排序：

count(字段) < count(主键id) < count(1) 约等于 count(*),所以建议尽量使用 count(*)