MySQL实战45讲Day13----count这么慢，我该怎么办

一、count(*)的实现方式：

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

  MyISAM引擎把一个表的总行数存在了磁盘上，因此执行count(*)的时候会直接返回这个数，效率很高，但是不支持事务；
  对于InnoDB引擎，它执行count(*)的时候，需要把数据一行一行地从引擎里面读出来，然后累加计数。虽然结果准确，但会导致性能问题。
这里需要注意的是，这里讨论的是没有过滤条件的count(*)，如果加了where 条件的话，MyISAM表也是不能返回得这么快的。

 2、InnoDB不跟MyISAM一样，把数字存起来的原因：

  因为即使是在同一个时刻的多个查询，由于多版本并发控制（MVCC）的原因，InnoDB表“应该返回多少行”也是不确定的。每一行记录都要判断自己是否对这个会话可见，因此对于count(*)请求来说，InnoDB只好把数据一行一行地读出依次判断，可见的行才能够用于计算“基于这个查询”的表的总行数。

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

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

 5、所以，计数的时候一般不使用count(*)，而采用自己计数的方式。

二、自己计数的方法：

1、用缓存系统保存计数。

 a、计数方式：

  用一个Redis服务来保存这个表的总行数。这个表每被插入一行Redis计数就加1，每被删除一行Redis计数就减1。

 b、优点：

  读和更新操作都很快。

 c、缺点：

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

2、用数据库计数。

 a、计数方式：

  把计数直接放到数据库里单独的一张计数表中。

 b、优点：

  首先解决了崩溃丢失的问题，因为InnoDB是支持崩溃恢复不丢数据的。其次由于InnoDB支持事务，可以通过事务的隔离级别，解决计数不精确的问题。

 c、缺点：

  需要额外的空间来存储这张表。

3、把计数放在Redis里面，不能够保证计数和MySQL表里的数据精确一致的原因，是这两个不同的存储构成的系统，不支持分布式事务，无法拿到精确一致的视图。而把计数值也放在MySQL中，就解决了一致性视图的问题。

三、不同count的用法：

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

 2、对于count(1)来说，InnoDB引擎遍历整张表，但不取值。server层对于返回的每一行，放一个数字“1”进去，判断是不可能为空的，按行累加。单看这两个用法的差别的话，可以对比出来，count(1)执行得要比count(主键id)快。因为从引擎返回id会涉及到解析数据行，以及拷贝字段值的操作。

 3、对于count(字段)来说：

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

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

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

 5、按照效率排序的话，count(字段)

、四、分析性能差别的原则：

 1、server层要什么就给什么；

 2、InnoDB只给必要的值；

 3、现在的优化器只优化了count(*)的语义为“取行数”，其他“显而易见”的优化并没有做。