MySQL COUNT(*)、COUNT(1)、COUNT(id)、COUNT(字段)效果及性能

前言

业务开发中，我们经常要使用count做一些数据统计。今天根据MySQL5.7官方文档及丁奇老师的MySQL45讲，介绍一下COUNT(*)、COUNT(1)、COUNT(id)、COUNT(字段)效果及性能。

COUNT(exper)

COUNT(exper) 返回由 SELECT 语句检索到的行中，expr 非 NULL 值的数量，结果是一个 BIGINT 类型的值。如果没有匹配的行，结果为0。

COUNT(*)

COUNT(*)它返回的是检索到的行数，无论这些行是否包含 NULL 值。

那么问题来了，如果SQL中没有WHERE条件，只是统计一个总数，MySQL为啥不弄总行数计数器？需要时直接返回，效率肯定高。没错，MyISAM引擎就是这做的，它把一个表的总行数存在了磁盘上，因此执行COUNT(*)的时候会直接返回。

但InnoDB却不能这样做，官方也给出了原因：

对于事务性存储引擎，如InnoDB，存储一个精确的行数会有问题的。如果同时发生多个事务，每个事务看到的总行数应该是不同的。SELECT COUNT(*) 语句只会计算当前事务可见的行数。存储一个精确的行，结果都相同了，不能保证事务的隔离性了！

优化

在 MySQL 5.7.18 之前，InnoDB 通过扫描聚集索引来处理 SELECT COUNT(*) 语句。从 MySQL 5.7.18 开始，除非索引或优化器提示指定了使用不同的索引，否则 InnoDB 会通过遍历最小的可用二级索引来处理 SELECT COUNT(*) 语句。如果不存在二级索引，则会扫描聚集索引。
这是因为聚集索引（或叫主键索引）叶子节点存储的是数据，而二级索引（或叫普通索引）存储的是主键。二级索引的树磁盘空间是要小于主键索引的，遍历需要时间更短。
这里提一下，索引字段值为null的情况。在MySQL的InnoDB存储引擎中，对于索引中的NULL值处理方式是将所有具有相同NULL值的记录放在索引树的同一位置，但并不是说所有的NULL值只占用一个节点。实际上，每个包含NULL值的记录都会在索引中有自己的条目，这些条目会聚集在一起。

COUNT(*) 与COUNT(1)

二者在操作上是一样的，无性能差异。但是前文中提到，COUNT(*)有优化，所以COUNT(*)应该略快于COUNT(1)

COUNT(1)

InnoDB引擎遍历整张表，但不取值。对于返回的每一行，放一个
数字“1”进去，判断这个值不可能为null，累加，返回总数。

COUNT(id)

InnoDB引擎会遍历整张表，取出每一行的id，判断这个值不可能为null，累加，返回总数。
count(1)不需要取值，count(id)需要取值，所以count(1)执行得要比count(主键id)快

COUNT(字段)

如果字段定义为NOT NULL。从每一行记录里读出这个字段不会为空，直接按行累加，返回总数。

如果字段定义为 可为NULL。从每一行记录里读出这个字段值可能为空，需要取出这个字段值，判断是否为空，不为空就累加。

总结

• 效果上 COUNT(*)=COUNT(1)=COUNT(id)，都是统计满足条件的总行数，不考虑是否为null。COUNT(字段)是要考虑是否为空。
• 性能上 COUNT(*)>COUNT(1)>COUNT(id)>COUNT(字段)
• 能用COUNT(*)就用COUNT(*)

个人感觉，COUNT(1)和COUNT(id)没有存在必要，可以放弃掉，这样简单一点，哈哈哈哈哈哈
！

参考

MySQL5.7官方文档