MySQL优化之：mysql count(*) 执行慢的解决思路和方案

前言：

在开发工作中，经常需要计算一个表的行数，比如一个内容系统审核记录总数。这时候我们最先想到是一条 select count(*) from my_table;语句。但是，随着系统（表）中记录数越来越多，这条查询语句执行的也会越来越慢。难道MySQL不会单独记个总数，我们每次要查的时候直接读出来？

那么就通过这一篇来聊聊count(*)语句到底是怎样实现的，以及 MySQL为什么会这么实现。如果在开发应用中有这样的需求，业务设计上可以怎么去做。

一、 count(*) 的实现方式

1、实现方式比较

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

• MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行 count(*) 的时候会直接返回这个数，效率很高；
• 而 InnoDB 引擎执行 count(*) 的时候，需要把数据一行一行地从引擎里面读出来，然后累积计数。这样就比较麻烦了。

【注意】在这篇学习文章里，是没有where过滤条件的count(*)，如果加了where条件，使用MyISAM引擎的表返回结果也不会变的很快。

2、为什么InnoDB不像MyISAM一样，也把数字存起来

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

在InnoDB引擎四个隔离级别（读未提交RU；读已提交RC；可重复读RR；可串行化Serializable）中，而MVCC只适用于RC和RR。
MVCC：Multi-Version Concurrency Control，就是在事务执行过程中加入“版本”这个概念、MVCC的实现：通过保存数据在某个时间点的快照来实现的。

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

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

如果从上到下是按照时间顺序执行的，同一行语句是在同一时刻执行的。下图表为会话 A、B、C 的执行流程。

从上图表中可以看到，在最后一个时刻，三个会话会同时查询表 test 的总行数，但结果却不同。

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

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

如果使用 show table status 命令，输出结果里面也有一个TABLE_ROWS 用于显示这个表当前有多少行，这个命令执行挺快的，那 TABLE_ROWS 能代替 count(*)么？

索引统计的值是通过采样来估算的。实际上，TABLE_ROWS 就是从这个采样估算得来的，因此它很不准。官方文档说误差可能达到 40% 到 50%。所以，show table status 命令显示的行数也不能直接使用。

3、小结

• MyISAM 引擎表虽然 count(*) 很快，但是不支持事务；
• show table status 命令虽然返回很快，但是不准确；
• InnoDB 引擎表直接 count(*)会遍历全表，虽然结果准确，但会导致性能问题。

那么，回到本文章开头的问题，如果在一个页面经常要显示内容系统的操作记录总数，这样的话，我们只能自己计数。下面我们来看看有哪些计数方法，以及每种方法的优缺点有哪些。基本思路：自己找一个地方，把操作记录表的行数存起来。

二、计数方法

1、用缓存系统保存计数

对于更新很频繁的库来说，我们第一时间想到的是用缓存系统来保存。比如用 Redis 服务来保存这个表的总行数。这个表插入一行时， Redis 计数就加 1，删除一行时， Redis 计数就减 1。这种方式下，读和更新操作都很快，但缓存系统可能会丢失更新，导致数据错误。

Redis 的数据不能永久地留在内存里，所以你会找一个地方把这个值定期地持久化存储起来。但即使这样，仍然可能丢失更新。如果刚刚在数据表中插入了一行，Redis 中保存的值也加了 1，然后 Redis 异常重启了，重启后你要从存储 redis 数据的地方把这个值读回来，而刚刚加 1 的这个计数操作却丢失了。

这种情况也可以解决，如果Redis 异常重启以后，到数据库里面单独执行一次 count(*) 获取真实的行数，再把这个值写回到 Redis 里就可以了。异常重启毕竟不是经常出现的情况，这一次全表扫描的成本，还是可以接受的。但在应用中，将计数保存在缓存系统中，还不只是丢失更新的问题。这个值在逻辑上也是不精确的。，

注意是逻辑不准确。

你可以设想一下有这么一个页面，要显示操作记录的总数，同时还要显示最近操作的 50 条记录。那么，这个页面的逻辑就需要先到 Redis 里面取出计数，再到数据表里面取数据记录。

我们是这么定义不精确的：

• 一种是，查到的 50 行结果里面有最新插入记录，而 Redis 的计数里还没加 1；
• 另一种是，查到的 50 行结果里没有最新插入的记录，而 Redis 的计数里已经加了 1。

这两种情况，都是逻辑不一致的。

我们一起来看看这个时序图：

上图中，会话 A 是一个插入记录的逻辑，往数据表里插入一行，然后 Redis 计数加 1；会话 B 就是查询页面显示时需要的数据。在这个时序里，在 T3 时刻会话 B 来查询的时候，会显示出新插入的这个记录，但是 Redis 的计数还没加 1。这时候，就会出现我们说的数据不一致。

即使把会话 A 的更新顺序换一下，再看看执行结果。

即使反过来，会话 B 在 T3 时刻查询的时候，Redis 计数加了 1 了，但还查不到新插入的 R 这一行，也是数据不一致的情况。

在并发系统里面，我们是无法精确控制不同线程的执行时刻的，因为存在图中的这种操作序列，所以，我们说即使 Redis 正常工作，这个计数值还是逻辑上不精确的。

2、在数据库保存计数

用缓存系统保存计数有丢失数据和计数不精确的问题。那么，如果我们把这个计数直接放到数据库里单独的一张计数表 A 中，会怎么样呢？

首先，解决了崩溃丢失的问题，InnoDB 是支持崩溃恢复不丢数据的。然后，再看看能不能解决计数不精确的问题。这也是我们要解决的问题，由于 InnoDB 要支持事务，从而导致 InnoDB 表不能把 count(*) 直接存起来，然后查询的时候直接返回形成的。

现在我们就利用“事务”这个特性，把问题解决掉。

执行结果：虽然会话 B 的读操作仍然是在 T3 执行的，但是因为这时候更新事务还没有提交，所以计数值加 1 这个操作对会话 B 还不可见。

因此，在会话 B 看到的结果里， 查计数值和“最近 50 条记录”看到的结果，逻辑上就是一致的。

三、不同的 count 用法

在 select count(?) from test 这样的查询语句里面，count(*)、count(主键 id)、count(字段) 和 count(1) 等不同用法的性能，这几种用法有啥性能差别呢？

【注意】下面学习的也是基于 InnoDB 引擎的。

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

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

在分析性能差别时，我们需要记住这么几个原则：

• server 层要什么就给什么；
• InnoDB 只给必要的值；
• 现在的优化器只优化了 count(*) 的语义为“取行数”，其他“显而易见”的优化并没有做。

1、 count(主键 id)

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

2、count(1)

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

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

3、count(字段)

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

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

4、count(*)

count(*)是例外，并不会把全部字段取出来，而是专门做了优化，不取值。count(*)肯定不是 null，按行累加。按照效率排序的话，count(*) = count(1) > count(主键 id) > count(字段)，所以建议尽量使用 count(*)。

到此这篇关于MySQL中count(*)执行慢的解决方案的文章就介绍到这了,更多相关MySQL执行count(*)内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！