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

首先需要声明,下面的内容主要是基于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。
这两种情况,都是逻辑不一致的。我们一起来看看这个时序图。


图 2 会话 A、B 执行时序图

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

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

2存入另一张表,使用事务

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值