mysql中count的理解与使用

转载：https://blog.csdn.net/h2604396739/article/details/85170051

2018年12月21日 19:39:25 深山猿 阅读数：6351

版权声明：转载请注明出处 https://blog.csdn.net/h2604396739/article/details/85170051

首先需要声明，下面的内容主要是基于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(*),那么应该怎么正确获取

如果你频繁使用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 还不可见。