比较喜欢的一段话：不经一番寒彻骨，怎得梅花扑鼻香 阅读这篇文章大概需要20分钟！
大家好前面我们大概了解了为什么delete from表名，表的大小还是没有变小！以及数据删除流程，数据页空洞，online和inplace。重建表的两种实现方式。今天介绍一下为什么count(*)那么慢。
count(*)实现方式
今天介绍的是MySQL的两种常用的引擎方式。第一种是最早期的MySQL默认引擎：myisam。第二种就是当下最流行的MySQL默认引擎innodb。两种引擎的实现方式各不相同。下面我们来分析一下。
myisam
myisam引擎在处理countI(*)时，速度是非常快的。因为myisam的设计思路就是，会把一个表的统计总数存在一个磁盘上。当用户count这个语句的时候。不需要把这个表中的数据全部查一遍，只需要把这个数据页上的统计数据取出来就可以了。所以myisam在这一点效率是非常高的。
但是在有一点myisam是的性能是非常差的。就是当这个count语句的时候后面加了一个where条件的时候，myisam与innodb一样。会采用从磁盘读取数据累计的手法。这样性能也就慢了下来。
innodb
innodb相比myisam就弱了一些。innodb独特的存储方式并没有采用这种方式。因为innodb兼顾着事务的特性，与mvcc多并发版本的实现，无法确保应该返回多少行，会有一个一致性的问题。所以innodb没有采用这种方式。innodb的处理方式是把当前数据表中的所有数据全部捞取到内存上。然后进行统计计数。
举例说明
假设表 t 中现在有 10000 条记录，我们设计了三个用户并行的会话。
- 会话 A 先启动事务并查询一次表的总行数；
- 会话 B 启动事务，插入一行后记录后，查询表的总行数；
- 会话 C 先启动一个单独的语句，插入一行记录后，查询表的总行数。
我们假设从上到下是按照时间顺序执行的，同一行语句是在同一时刻执行的。
你会看到，在最后一个时刻，三个会话 A、B、C 会同时查询表 t 的总行数，但拿到的结果却不同。
这和 InnoDB 的事务设计有关系，可重复读是它默认的隔离级别，在代码上就是通过多版本并发控制，也就是 MVCC 来实现的。每一行记录都要判断自己是否对这个会话可见，因此对于 count(*) 请求来说，InnoDB 只好把数据一行一行地读出依次判断，可见的行才能够用于计算“基于这个查询”的表的总行数。
count(*)优化
性能那么慢不需要优化吗？肯定是需要优化的。那么是如何优化的呢？
InnoDB 是索引组织表，主键索引树的叶子节点是数据，而普通索引树的叶子节点是主键值。所以，普通索引树比主键索引树小很多。对于 count(*) 这样的操作，遍历哪个索引树得到的结果逻辑上都是一样的。因此，MySQL 优化器会找到最小的那棵树来遍历。在保证逻辑正确的前提下，尽量减少扫描的数据量，是数据库系统设计的通用法则之一。
扩展一个语法：跟统计行数相同的还有一个SQL是 show table status 这个语句也会返回相应的行数。但是这个行数是极其不准的，他是通过一种采样来估算的。table_rowsu是从这种估算得来的。据官方介绍误差大概在40-50%。
小结
- MyISAM 表虽然 count(*) 很快，但是不支持事务；
- show table status 命令虽然返回很快，但是不准确；
- InnoDB 表直接 count(*) 会遍历全表，虽然结果准确，但会导致性能问题。
用缓存系统保存计数
上面介绍了innodb与myisam对count的计数的性能都是非常不友好的，那么我们可不可以基础count计数设计一个系统用来专门计数呢。
你可以第一时间会想到缓存系统，说到缓存系统肯定第一时间也会想到Redis。Redis的性能是非常好的，但是有一个通病就是。当MySQL跟Redis协同完全缓存计数的时候。就会存在丢失更新的状况。
举例说明
试想如果刚刚在数据表中插入了一行，Redis 中保存的值也加了 1，然后 Redis 异常重启了，重启后你要从存储 redis 数据的地方把这个值读回来，而刚刚加 1 的这个计数操作却丢失了。
当然了，这还是有解的。比如，Redis 异常重启以后，到数据库里面单独执行一次 count(*) 获取真实的行数，再把这个值写回到 Redis 里就可以了。异常重启毕竟不是经常出现的情况，这一次全表扫描的成本，还是可以接受的。
但实际上，将计数保存在缓存系统中的方式，还不只是丢失更新的问题。即使 Redis 正常工作，这个值还是逻辑上不精确的。
你可以设想一下有这么一个页面，要显示操作记录的总数，同时还要显示最近操作的 100 条记录。那么，这个页面的逻辑就需要先到 Redis 里面取出计数，再到数据表里面取数据记录。
下列两种情况都是不对的
- 查到的 100 行结果里面有最新插入记录，而 Redis 的计数里还没加 1；
- 查到的 100 行结果里没有最新插入的记录，而 Redis 的计数里已经加了 1。
看图我们继续分析一下
如上图会话 A 是一个插入交易记录的逻辑，往数据表里插入一行 R，然后 Redis 计数加 1；会话 B 就是查询页面显示时需要的数据。
在这个时序里，在 T3 时刻会话 B 来查询的时候，会显示出新插入的 R 这个记录，但是 Redis 的计数还没加 1。这时候，就会出现我们说的数据不一致。
你一定会说，这是因为我们执行新增记录逻辑时候，是先写数据表，再改 Redis 计数。而读的时候是先读 Redis，再读数据表，这个顺序是相反的。那么，如果保持顺序一样的话，是不是就没问题了？我们现在把会话 A 的更新顺序换一下，再看看执行结果。
你会发现，这时候反过来了，会话 B 在 T3 时刻查询的时候，Redis 计数加了 1 了，但还查不到新插入的 R 这一行，也是数据不一致的情况。在并发系统里面，我们是无法精确控制不同线程的执行时刻的，因为存在图中的这种操作序列，所以，我们说即使 Redis 正常工作，这个计数值还是逻辑上不精确的。
在数据库保存计数呢
在文章一开始的时候，说过不能在数据表里保存计数，这里又绕了回来。我相信很多小伙伴都糊涂了。先带着糊涂看完再一一介绍好吧，
我们直接统一放在一个表中。首先就要解决数据崩溃的问题。而innodb是支持数据崩溃不丢数据的。
然后我们再解决数据准确性问题。
我们这篇文章要解决的问题，都是由于 InnoDB 要支持事务，从而导致 InnoDB 表不能把 count(*) 直接存起来，然后查询的时候直接返回形成的。所谓以子之矛攻子之盾，现在我们就利用“事务”这个特性，把问题解决掉。如上图
我们来看下现在的执行结果。虽然会话 B 的读操作仍然是在 T3 执行的，但是因为这时候更新事务还没有提交，所以计数值加 1 这个操作对会话 B 还不可见。因此，会话 B 看到的结果里， 查计数值和“最近 100 条记录”看到的结果，逻辑上就是一致的。
不同count()语句的流程
首先你要弄清楚 count() 的语义。count() 是一个聚合函数，对于返回的结果集，一行行地判断，如果 count 函数的参数不是 NULL，累计值就加 1，否则不加。最后返回累计值。
count(*)
表示所有数据中，不管是不是null，都算在内。具体的流程是从磁盘IO上读取数据，放到内存中然后一个一个累计计数。
因为MySQL内部优化问题，不会取值
count(字段)
表示所有的数据中，不为null的所有数据的累计。具体流程是从从磁盘IO上读取相应的字段数据，放到内存中然后判断当前数值是否为null。只有不为null的值才进行累计计数。
count(1)
InnoDB 引擎遍历整张表，但不取值。server 层对于返回的每一行，放一个数字“1”进去，判断是不可能为空的，按行累加
综上所述：按照效率排序的话，count(字段) < count(主键 id) < count(1) ≈ count( )。所以还是建议你尽量使用count( )
微信公众号【欢少的成长之路】 有任何不懂的地方都可以一起讨论学习