第二十节、count(*)这么慢，我该怎么办

count(*)的实现方式

在不同的MySQL引擎中，count(*)有不同的实现方式。

1、MyISAM引擎把一个表的总行数存在了磁盘上，因此执行count(*)的时候会直接返回这个数，效率很高；如果加了where条件的话，MyISAM表也是不能返回得这么快的。

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

---

为什么InnoDB不跟MyISAM一样也把数字存起来？

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

---

InnoDB对count(*)做的优化？

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

show table status 命令

这个命令的输出结果里面页有一个TABLE_ROWS用于显示这个表当前有多少行,但是这个命令跟索引统计一样都是通过采样来估算的，因此不是很准确，误差可能达到40%到50%。所以这个命令也不能直接使用。

---

如果需要经常显示交易系统的操作记录总数，该怎么办？

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

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

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

所以基本思路：找一个地方，把操作记录表的行数存起来

用缓存系统保存计数

缺点：将计数保存在缓存系统中的方式，不只是丢失更新，而且值在逻辑上可能不精确。适用于统计大概数，对数值精确度要求不高的业务中。

在数据库保存计数

将计数直接放到数据库里单独的一张计数表C中，解决了崩溃丢失问题，InnoDB是支持崩溃恢复不丢数据的。

---

不同的count用法

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

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

3、对于count(字段)来说：

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

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

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

所以结论是：按照效率排序的话，count(字段),count(主键ID)

---

小结

把计数放在redis里面，不能够保证计数和myslq表里的数据精确一致的原因是：这两个不同的存储构成的系统，不支持分布式事务，无法拿到精确一致的视图。而把计数值也放在mysql中，就解决了一致性视图的问题。InnoDB引擎支持事务，利用好事务的原子性和隔离性，就可以简化在业务开发时的逻辑。