MySQL 中count（*）的实现方式：

    1、 MyISAM 引擎是把一个表的总行数存在了磁盘上，因此执行count(*) 的时候会直接返回这个数，相对来说效率很高；

    2、对于InnoDB 引擎在执行count(*) 的时候，需要把数据一行一行的从引擎里面读出来，然后进行累计计数。

那InnoDB为什么也不存起来呢？

    这是因为InnoDB是多版本并发控制（MVCC）的原因。InnoDB表“应该返回多少行”也是不确定的。

    例：

    假设表t中现在有10000条记录，我们设计了三个用户并行的会话。

• 会话A先启动事务并查询一次表的总行数；

• 会话B启动事务，插入一行后记录后，查询表的总行数；

• 会话C先启动一个单独的语句，插入一行记录后，查询表的总行数。

  
  

在最后一个时刻，三个会话A、B、C 会同时查到表  t 的总行数，但是拿到的结果却是不同的。

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

InnoDB是索引组织表，主键索引树的叶子节点是数据，而普通索引树的叶子节点是主键值。所以，普通索引树比主键索引树小很多。对于count(*)这样的操作，遍历哪个索引树得到的结果逻辑上都是一样的。因此，MySQL优化器会找到最小的那棵树来遍历。在保证逻辑正确的前提下，尽量减少扫描的数据量，是数据库系统设计的通用法则之一。

show table status 命令的统计结果也有个TABLE_ROWS 用于显示当前表有多少行，执行速度也挺快的，但实际上索引统计的值是通过采样来估算的。因此它也很不准。有多不准呢，官方文档说误差可能达到40%到50%。所以，show table status命令显示的行数也不能直接使用。

综上所述：

• MyISAM表虽然count(*)很快，但是不支持事务；

• show table status命令虽然返回很快，但是不准确；

• InnoDB表直接count(*)会遍历全表，虽然结果准确，但会导致性能问题。

  
  

不同的count用法

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

首先 count()是一个聚合函数，对于返回的结果集，一行行地判断，如果count函数的参数不是NULL，累计值就加1，否则不加。最后返回累计值。

所以，count(*)、count(主键id)和count(1) 都表示返回满足条件的结果集的总行数；而count(字段），则表示返回满足条件的数据行里面，参数“字段”不为NULL的总个数。

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

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

  单看这两个用法的差别的话，你能对比出来，count(1)执行得要比count(主键id)快。因为从引擎返回id会涉及到解析数据行，以及拷贝字段值的操作。

• count(字段)来说：

  1、如果这个“字段”是定义为not null的话，一行行地从记录里面读出这个字段，判断不能为null，按行累加；

  2、如果这个“字段”定义允许为null，那么执行的时候，判断到有可能是null，还要把值取出来再判断一下，不是null才累加。

• count(*)是例外，并不会把全部字段取出来，而是专门做了优化，不取值。count(*)肯定不是null，按行累加。

所以结论是：

按照效率排序的话，count(字段)<count(主键id)<count(1)≈count(*)，所以个人建议，尽量使用count(*)

注：本文主要讲的是InnoDB