Innodb中count的理解,count(*)存储使用缓存或者事务

比眉伴天荒 2022-04-03 10:28 248阅读 0赞

首先需要声明，下面的内容主要是基于innodb；myIsam中会单独存储count(\*)的值，因此会直接返回，效率最高。

## innodb为什么不单独存储count(\*)的值 ##

这是因为innodb支持事务和mvcc，同一个时刻，存在多个事务，然后每个事务都有插入或者删除操作，那么这个count(\*)的值就没有办法维护了。其实我的观点是innodb完全可以将mvcc用于count(\*)的值维护，这样在不同事务中count(\*)就可以区分了，但遗憾的是mysql并没有这样做。

##    count(\*),count(1),count(主键)，count(字段) ##

1.  count(字段)：innodb遍历整张表，按行定位到主键，然后指针移动获取指定行的值返回给server层，如果字段定义为not null,直接加1；如果字段值可以为null，则先判断取到的值是否为null，为null则不加1，否则加一
2.  count(主键)：InnoDB 引擎会遍历整张表，把每一行的 id 值都取出来，返回给 server 层。server 层拿到 id 后，判断是不可能为空的，就按行累加。
3.  count(1):InnoDB 引擎遍历整张表，但不取值。server 层对于返回的每一行，放一个数字“1”进去，判断是不可能为空的，按行累加。
4.  count(\*):   count(\*) 是例外，并不会把全部字段取出来，而是专门做了优化，不取值。count(\*) 肯定不是 null，按行累加。

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

##    如果频繁使用count(\*),那么应该怎么正确获取 ##

如果你频繁使用count(\*)，每次都要执行count操作，肯定不合理，你可能想到放到缓存中，然后去维护这个值

##    1存入缓存方式 ##

Redis 正常工作，这个值还是逻辑上不精确的。   
你可以设想一下有这么一个页面，要显示操作记录的总数，同时还要显示最近操作的 100 条记录。那么，这个页面的逻辑就需要先到 Redis 里面取出计数，再到数据表里面取数据记录。  
我们是这么定义不精确的：  
一种是，查到的 100 行结果里面有最新插入记录，而 Redis 的计数里还没加 1；  
另一种是，查到的 100 行结果里没有最新插入的记录，而 Redis 的计数里已经加了 1。  
这两种情况，都是逻辑不一致的。我们一起来看看这个时序图。

![2018122119392618][]  
图 2 会话 A、B 执行时序图

图 2 中，会话 A 是一个插入交易记录的逻辑，往数据表里插入一行 R，然后 Redis 计数加 1；会话 B 就是查询页面显示时需要的数据。  
在图 2 的这个时序里，在 T3 时刻会话 B 来查询的时候，会显示出新插入的 R 这个记录，但是 Redis 的计数还没加 1。这时候，就会出现我们说的数据不一致。  
你一定会说，这是因为我们执行新增记录逻辑时候，是先写数据表，再改 Redis 计数。而读的时候是先读 Redis，再读数据表，这个顺序是相反的。那么，如果保持顺序一样的话，是不是就没问题了？我们现在把会话 A 的更新顺序换一下，再看看执行结果。

![2018122119392639][]

图3  
你会发现，这时候反过来了，会话 B 在 T3 时刻查询的时候，Redis 计数加了 1 了，但还查不到新插入的 R 这一行，也是数据不一致的情况。  
在并发系统里面，我们是无法精确控制不同线程的执行时刻的，因为存在图中的这种操作序列，所以，我们说即使 Redis 正常工作，这个计数值还是逻辑上不精确的。

### 2存入另一张表，使用事务 ###

![20181221193926149][]

我们来看下现在的执行结果。虽然会话 B 的读操作仍然是在 T3 执行的，但是因为这时候更新事务还没有提交，在可重复读（innodb默认隔离级别）隔离级别下，计数值加 1 这个操作对会话 B 还不可见。

[2018122119392618]: /images/20220403/929d1a372fa7415b850702e3fffffa72.png
[2018122119392639]: /images/20220403/0364d91ff6864d1f98f48ea0cbba2e75.png
[20181221193926149]: /images/20220403/b6e9a9defeac41e1ad35306fa19580f1.png