14 - count（*）怎么优化

关键字

count(*)、计算表行数

0.引子

在很多时候，你需要计算一个表的行数，比如计算一个交易系统中所有的变更记录的综述。一般情况下，我们使用一条简单的 select count(*) from t 的语句就可以解决。

但是，如果系统中的记录数越来越多，这个语句的执行也会越来越慢。这个问题看似很好解决，但是在不同的引擎下有不同的实现方式，

1.count(*)的实现方式

在 MyISAM 引擎中，它将表的总行数存在了磁盘上，所以对它使用 count(*) 会非常高效。
在 InnoDb 引擎中，它执行 count(*) 的时候，需要将数据一行一行读出来，然后累积计数。

为什么 InnoDB 不将数据行数直接存储呢？主要是因为它支持多版本并发控制（MVCC），且 InnoDB 中的默认事务隔离级别为可重复读，所以即使在同一时刻，它应当返回多少行也是不确定的。我们可以用下面的例子解释：

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

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

我们假设从上到下是按照时间顺序执行的，同一行语句是在同一时刻执行的，它的执行结果如下：

14-并行流程.png

可以发现，三个会话拿到了不同的结果。在这里，有几点需要注意：

即使 InnoDB 使用了逐行扫描，但是它在内部也进行了优化：普通索引树比主键索引树小，遍历普通索引树的叶子节点（主键值）会比直接遍历主键索引树的叶子节点（数据）快。因此，优化器会找到最小的那棵树遍历。
上面提到了数据库设计的通用法则之一：在保证逻辑正确的前提下，尽量减少扫描的数据量。
不可以使用 show table status ：使用这个命令可以查看表的行数，但是如第十节中所讲的，它是一个估算值，误差甚至可以达到 50%。

到了这里，你会发现，使用 InnoDB 似乎只能自己计数，那么该如何选择计数方法呢？

2.计数方法

2.1使用缓存计数

使用缓存计数应该是首先想到的方法，它比较简单，但是也会有一些问题（以 redis 为例）：

如果 redis 异常重启，可能会造成数据丢失。这可以通过持久化存储或遍历数据表来避免。
非常致命的一点：即使 redis 正常工作，在进行频繁插入和读取的时候，这个值在逻辑上仍然是不精确的。你可以通过下面两个例子自己思考一下：

14-使用缓存，数据不一致.png

14-使用缓存，数据不一致2.png

你会发现，由于无法精确控制不同线程的执行时刻，所以不论怎样设计计数逻辑，它都是不够精确的。

2.2使用数据库保存计数

第二种解决方法，是将计数值单独存放在一个表中。那我们看一看，对于之前 redis 面临的问题，在这个方法下能否解决呢？

意外重启问题：InnoDB 拥有 redo log ，可以很好的解决崩溃丢失的问题。
数据不一致的问题：我们可以使用事务隔离很好地解决这个问题，看一下下面的例子：

14-使用表计数.png

你会发现，即使会话 B 在 T3 时刻执行，但是由于会话A 并没有提交，因此它不会看到计数值 +1 的操作。此时，它读出的计数值和最近 100 条记录在逻辑上就是一直的了。

了解了计数的办法，我们还可以稍微看一下不同 count 的性能差别。

3.不同 count 的用法

对于 count 一般我们有几种用法：count(*)，count(主键 id)，count(字段)，count(1)等。我们来看一下与之相关的定义，以及不同 count 的性能（依然在 InnoDB 引擎下）：

count 是一个聚合函数，对于返回的结果集，一一进行判断，如果 count 函数的参数不是 NULL，累计值就 +1 ，否则不加。最后返回累计值。
对于性能分析，有以下几个原则：
1.sever 层要什么就给什么。
2.InnoDB 只给必要的值。
3.优化器值优化了 count(*) 的语义（即“取行数”的意思），其它方面的优化并没有做。
count(主键id)：使用这个方式，InnoDB 会遍历整个表，把所有的 id 值都传给 sever 层。sever 层拿到 id 后，可以直接按行累加（id 不能为空）。
count(1)：InnoDB 会遍历整个表，但是不取值。sever 对返回的每一行，都放一个数字 “1”，这个判断不可能为空，可以直接累加。
count(字段)：
1.如果这个字段为 not null，则读出字段，按行累加。
2.如果这个字段为允许 null，在执行的时候，需要将值取出判断，如果不是 null 才累加。
count(*)：不会取出全部字段，而是专门做了优化，按行累加。

综上，按照效率排序，count(字段) < count(主键 id) < count(1) ≈ count(*)。所以，建议尽量使用count(*)

总结

不同引擎获取计数的方法是不同的，由于 InnoDB 支持（MVCC），所以计数的性能相对滞后。
使用 redis 计数，会出现无法拿到精确的一致性视图的情况。
可以将计数值单独放在一个表中，解决这个问题。
建议你使用 count(*)。

上期问题

上期的问题是，什么时候使用 alter table t engine=InnoDB 会让一个表占用的空间反而变大。

答案是，如果这个表的本身就没有空洞，再做一次重建操作。由于 InnoDB 会在建表的时候预留一部分空间（六分之一），所以加上预留空间，这个表占用的空间反而变大了。

本期思考

在刚刚讨论的方案中，我们用了事务来确保计数准确。由于事务可以保证中间结果不被别的事务读到，因此修改计数值和插入新记录的顺序是不影响逻辑结果的。但是，从并发系统性能的角度考虑，你觉得在这个事务序列里，应该先插入操作记录，还是应该先更新计数表呢？

以上就是全部内容，希望你可以找到最优解。

注：本文章的主要内容来自我对极客时间app的《MySQL实战45讲》专栏的总结，我使用了大量的原文、代码和截图，如果想要了解具体内容，可以前往极客时间