select count(*) 数据量大时，怎么解决他的慢？

mysql实战45讲笔记：

 

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

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

而 InnoDB 引擎就麻烦了，它执行 count(*) 的时候，需要把数据一行一行地从引擎里面读出来，然后累积计数。

 

数据量大了以后，innodb的方式自然就很慢，那么innodb自身是如何优化的呢？

因为innodb的B+索引存放数据的方式，所以只要从最小的索引树去取数据计算，就好了，在保证逻辑正确的前提下，尽量减少扫描的数据量，是数据库系统设计的通用法则之一。

那么，能不能有更好的方式呢？自然是有的，可以将数据行数记录起来。注意，如果使用redis等缓存或者其他的服务/进程级别的处理方式，基本上就是引入了分布式事务的问题了，因此数据一致性等问题没法保证。但是可以利用mysql的INNODB自身的特性，首先，INNODB支持事务，所以，count可以利用这一点，在事务中去对count()增删改查，这样，就能保证count()在不同事务间的准确了。

对两个会话来说，读到的count(）都是准确的。但是，最好是在事务的末尾对count数的记录表进行更新，这样可以最小限度的控制count()表的行锁竞争，毕竟如果有多个事务都需要对同一个表的count()数据进行update时，首先获取到行锁的事务如果不尽快提交，后面的事务就会被阻塞。

 

 

最后对count()常见的问题做一下总结：

count(id)，count(*)，count(字段)，count(1)，他们的实现方式和性能差异？

分析性能差别的时候，可以记住这么几个原则：

server 层要什么就给什么；

InnoDB 只给必要的值；

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

所以，对于count(1)，innodb只返回了行数，没有返回数据，server给每行放进去个1，然后判断返回的数据定义，如果可能为null，判断值是不是null，然后统计；

对于count(字段)，如果innodb读取字段数据，返回字段数据，server读取字段，判断字段属性可否为null，如果可以为null，再判断值是否为null，然后统计，

对于count(id)，innodb读取id主键数据,（当然也可以从其他索引得到id，减小数据的io）然后返回server，server判断字段属性可否为null;主键不可能为null，直接统计；

对于coung(*)，innodb做了优化，不取数据，只返回行数，然后server判断是否为null，不可能为null，直接统计；

 

所以，性能count(*) > count(1)>count(id)> count(字段)，

可以从：

需要读取数据行传输数据，需要放入值，需要判断字段属性，需要判断字段值，从这几个方面去考虑。