原文《MySQL实战45讲》
count(*)的实现方式
在MySQL中，不用的引擎对count(*)有不同的实现方式。
- MyISAM引擎把一个表的总行数存在了磁盘上，因此执行count()的时候会直接返回这个数，效率很高；（这里指的是没有过滤条件的count()，如果加了where条件的话，MyISAM表也是不能返回这么快)
- 而InnoDB引擎执行count(*)的时候，需要先将数据一行一行地从引擎里面读出来，然后再累积计数。
为什么InnoDB的实现方式和MyISAM不一样？
InnoDB支持多版本并发控制（MVCC），所以InnoDB表"应该返回多少行"也是不确定的。这与InnoDB的事务涉及有关，InnoDB默认的事务隔离级别是"可重复读"，在代码上就是通过多版本并发控制（MVCC）实现的。每一行记录都要判断自己是否对这个会话可见，因此对于count（*）请求来说，InnoDB需要将数据一行行读出并以此判断，可见的才能用于计算“基于这个查询”的表的总行数。
同时，InnoDB在执行count(*)操作的时候，有做了优化，InnoDB表是所以组织表，主键索引树的叶子节点是数据，而普通索引树的叶子节点是主键值。所以，普通索引书比主键索引树小很多。对于count ( *)，遍历哪棵索引树都是一样的，因此MySQL优化器会找到最小的那棵树来便利。（在保证逻辑正确的前提下，尽量减少扫描的数据量，是数据库涉及的通用法则之一）
show table status 中的 TABLE_ROWS 能代替 count(*) 吗
不能！索引统计的值是通过采样估算的，实际上，TABLE_ROWS 就是从这个采样估算得来的，因此它也很不准（官方文档说误差可能达到40%到50%）。所以，show table status 命令显示的行数也不能直接使用。
小结
- MyISAM表虽然count(*) 很快，但是不支持事务；
- show table status 命令虽然返回很快，但是不准确；
- InnoDB表直接count(*) 会遍历全表，虽然结果准确，但是会导致性能问题。
不同的count用法性能比较
在InnoDB引擎中，select count(?) from t 这样的查询语句里面，count(*)、count(主键id)、count(字段)和count(1)等不同用法的性能，有哪些差别。
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(*)
InnoDB在执行count(*) 的时候，并不会把全部字段取出来，而是专门做了优化，不取值。 而且count( *)肯定不为null，直接按行累加。
小结
所以结论是：按照效率排序的话，count(字段) < count(主键id) < count(1) ≈ count(*)
网友评论