count(*)的实现方式
在不同的MySQL引擎中，count(*)有不同的实现方式。
- MyISAM引擎把一个表的总行数存在了磁盘上，因此执行count(*)的时候会直接返回这个数，效率很高；
- innoDB引擎就麻烦了，它执行count(*)的时候，需要把数据一行一行地从引擎里面读出来，然后累积计数。
需要注意的是，这儿讨论的是没有过滤条件的count(*)，如果加了where条件的话，MyISAM表也不是这么快的。
那为什么InnoDB不跟MyISAM一样，也把数字存起来呢？
因为即使是在同一个时刻的多个查询，由于多版本并发控制（MVCC）的原因，InnoDB表“应该返回多少行”也是不确定的。
当然，MySQL对count(*)也是做了优化的。
InnoDB是索引组织表，主键索引树的叶子节点是数据，而普通索引树的叶子节点是主键值。所以，普通索引树比主键索引树小很多。对于count(*)这样的操作，遍历哪个索引树得到的结果逻辑上都是一样的。因此，MySQL优化器会找到最小那颗索引树来遍历。在保证逻辑正确的前提下，尽量减少扫描的数据量，是数据库系统设计的通用法则之一。
如过通过show table status命令的话，就会发现这个命令输出的结果里也有一个TABLE_ROWS用于显示这个表当前有多少行，这个命令执行挺快的，那这个TABLE_ROWS能代替count(*)吗？ 答案是不能，索引统计的值是通过采样来估算的，事实上，TABLE_ROWS就是从这个采样估算得来的，因此它也很不准确。官方文档说误差可能达到40%到50%。
总结：
- MyISAM表虽然count(*)很快，但是不支持事务；
- show table status命令虽然很快返回，但是不准确；
- InnoDB表直接count(*)会遍历全表，虽然结果准确，但是会导致性能问题。
有哪些方法可以计数，以及各自的优缺点：
用缓存系统保存计数
比如用Redis来保存一个表的总行数。表插入一行，Redis就加1，删除一行就减1。这种方式读写都很快。
但是缓存系统可能会丢失更新。
实际上，将计数保存在缓存系统中的方式，还不只是丢失更新的问题，即使Redis正常工作，这个值还是逻辑上不精确的。
比如如下两个图：
在数据库保存计数
把这个表的总行数直接放到数据库里单独的一张计数表C中，会怎么样？
首先，解决了奔溃丢失的问题，InnoDB是支持奔溃恢复不丢失数据的。
而且还可以解决上面计数不精确的问题。
因为InnoDB是支持事务的，默认隔离级别是可重复读，如下：
不同的count用法
select count(?) from t、count(*)、count(主键id)、count(1)
还是基于innoDB引擎.
首先弄清count()的语义。count()是一个聚合函数，对于返回的结果集，一行行地判断，如果count函数的参数不是null，累计值就加1,否则不加。最后返回累计值。
所以，count(*)、count(主键id)和count(1)都表示返回满足条件的结果集的总行数；而count(字段)，则表示返回满足条件的数据行里面，参数“字段”不为NULL的总个数。
分析性能差别的时候，可以记住这么几个原则：
- server层要什么就给什么；
- InnoDB只给必要的值；
- 现在的优化器只优化了count(*)的语义为“取行数”，其他“显而易见”的优化并没有做。
count(主键id)，InnoDB引擎会遍历整张表，把每一行的id值都取出来，返回给server层，server拿到id后，判断是不可能为空的，就按行累加。
count(1)，InnoDB引擎遍历整张表，但不取值。server层对于返回的每一行，放一个数字“1”进去，判断是不可能为空的，按行累加。
单看这两个，count(1)执行要比count(主键id)快，因为引擎返回id会涉及到解析数据行，以及拷贝字段值的操作。
count(字段)：如果这个“字段”是定义为not null的话，一行行地从记录里面读出这个字段，判断不能为null，就按行累加；如果这个“字段”定义允许为null，那么执行的时候，判断到有可能是null，还要把值取出来再判断一下，不是null才累加。
count(*)，这个比较例外，并不会把所有字段都取出来，而是专门做了优化，不取值。count(*)肯定不是null，就按行累计。
结论：按照效率排序：count(字段)<count(主键id)<count(1)≈count(*)，所以建议尽量使用count(*)
扫一扫
685
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
