count(*)、count(主键 id)、count(字段) 和 count(1) 等不同用法的性能差别

count(主键 id)：InnoDB 引擎会遍历整张表，把每一行的 id 值都取出来，返回给 server 层。server 层拿到 id 后，判断是不为空的，就按行累加
count(1)：InnoDB 引擎遍历整张表，但不取值。server 层对于返回的每一行，放一个数字“1”进去，判断是不为空的，按行累加
count(字段)：
如果这个 “字段” 是定义为 not null 的话，一行行地从记录里面读出这个字段，判断不能为 null，按行累加
如果这个 “字段” 定义允许为 null，那么执行的时候，判断到有可能是 null，还要把值取出来再判断一下，不是 null 才累加
count()：并不会把全部字段取出来，而是专门做了优化，不取值。count() 肯定不是 null，按行累加
按照效率排序的话：count(字段) < count(主键 id) < count(1) ≈ count()
所以，尽量使用 count()

count(*) 的实现方式

在不同的 MySQL 引擎中，count(*) 有不同的实现方式：

MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行 count() 的时候会直接返回这个数，效率很高
而 InnoDB 引擎就麻烦了，它执行 count() 的时候，需要把数据一行一行地从引擎里面读出来，然后累积计数
为什么 InnoDB 不跟 MyISAM 一样，也把数字存起来呢 ?

和 InnoDB 的事务设计有关系，可重复读是它默认的隔离级别，在代码上就是通过多版本并发控制，也就是 MVCC 来实现的。
每一行记录都要判断自己是否对这个会话可见，因此对于 count(*) 请求来说，InnoDB 只好把数据一行一行地读出依次判断，可见的行才能够用于计算“基于这个查询”的表的总行数。
MySQL 在查询总数的时候会找到最小的那棵树进行遍历，这也是优化的一部分

B+树只有叶子结点上有数据，全部遍历其实就是对叶子结点的链表进行遍历。
此时如果遍历主键索引树，由于其叶子结点上存放的是完整的行信息，对于一个数据页而言其行密度会比较小，最终导致要扫描的数据页较多，进而IO开销也比较大。
如果遍历第二索引树，其叶子结点只存放主键信息，其数据页的行密度比较大，最终扫描的数据页较少，节省了IO开销。
show table status 命令中的 TABLE_ROWS 能代替 count(*) 吗 ?

不能
实际上，TABLE_ROWS 是通过采样估算得来的，因此它也很不准。官方文档说误差可能达到 40% 到 50%。
所以，show table status 命令显示的行数也不能直接使用。

总结 count(*)

MyISAM 表虽然 count() 很快，但是不支持事务；
show table status 命令虽然返回很快，但是不准确；
InnoDB 表直接 count() 会遍历全表，虽然结果准确，但会导致性能问题

count(*)很慢怎么办？

用缓存系统保存计数

将计数保存在缓存系统中的方式，还不只是丢失更新的问题。即使 Redis 正常工作，这个值还是逻辑上不精确的。

这里主要原因是因为 “MySQL插入一行数据” 跟 “Redis计数加1” 这两个操作是分开的，不是原子性的，这就很可能在中间过程因为某些并发出现问题。
更抽象一点：MySQL 和 Redis 是两个不同的载体，将关联数据记录到不同的载体，而不同载体要实现原子性很难，由于不是原子性很容易引起并发问题。
如果能将数据统一在同个载体即 MySQL，并由其保证操作的原子性，即将插入一行数据和计数加1作为一个完整的事务，通过事务的隔离此时外界看到的就是要么全部执行完毕，要么全部都没执行，进而保持逻辑一致。

在数据库保存计数

在数据库中建表计数，可以得到精准的计数，方法是通过数据库中的事务来实现的。
计数器的修改和数据的写入都在一个事务中。
读取计数器和查询最近数据也在一个事务中。