count(*) 的实现方式

讨论的是没有过滤条件的 count(*)
在不同的 MySQL 引擎中，count(*) 有不同的实现方式。

MyISAM 引擎:
把一个表的总行数存在了磁盘上，直接返回这个数，效率很高；

InnoDB 引擎:
把数据一行一行地从引擎里面读出来(走最小的树的叶子节点的链表)，然后累积计数。

为什么要使用 InnoDB，因为不论是在事务支持、并发能力还是在数据安全方面，InnoDB 都优于 MyISAM

为什么InnoDB 不记录总行数

因为要支持事务
多版本并发控制MVCC, 每一行记录都要判断自己是否对这个会话可见，
因此对于 count(*) 请求来说，InnoDB 只好把数据一行一行地读出依次判断，可见的行才能够用于计算“基于这个查询”的表的总行数。

会找到最小的那棵树来遍历

InnoDB 是索引组织表，主键索引树的叶子节点是数据，而普通索引树的叶子节点是主键值。
所以，普通索引树比主键索引树小很多。
对于 count(*) 这样的操作，遍历哪个索引树得到的结果逻辑上都是一样的。

因此，MySQL 优化器会找到最小的那棵树来遍历。

在保证逻辑正确的前提下，尽量减少扫描的数据量，是数据库系统设计的通用法则之一。

如果自己来记录行数

用redis来记不行: 1. 崩溃丢失 2.并发, 如果取行数的同时 改数据 会不准确

用一个表来记录行数

会话A 在插入行, 会话B在读取行并且count, 因为事务隔离, A的修改对B就没影响, B自己是一致的

count(*)、count(主键 id)、count(字段) 和 count(1) 比较

count(字段)<count(主键 id)<count(1)≈count(*)

尽量使用 count(*)

• count(主键 id) : InnoDB 引擎会遍历整张表，把每一行的 id 值都取出来，返回给 server 层。server 层拿到 id 后，判断是不可能为空的，就按行累加。

• count(1) : InnoDB 引擎遍历整张表，但不取值。server 层对于返回的每一行，放一个数字“1”进去，判断是不可能为空的，按行累加。

• count(字段)：如果这个“字段”是定义为 not null 的话，一行行地从记录里面读出这个字段，判断不能为 null，按行累加；如果这个“字段”定义允许为 null，那么执行的时候，判断到有可能是 null，还要把值取出来再判断一下，不是 null 才累加。

• count(*) : 专门做了优化，不取值。count(*) 肯定不是 null，按行累加。

分析性能差别的时候，原则：

• server 层要什么就给什么；
• InnoDB 只给必要的值；

现在的优化器只优化了 count(*) 的语义为“取行数”，其他“显而易见”的优化并没有做。也就是前面的第一条原则，server 层要什么字段，InnoDB 就返回什么字段。