关于 MySQL 百万数据量的 count(*) 查询如何优化？

明确需求

对这个问题有兴趣是源于一次开发中遇到要统计人数的需求。相似于“获得”专栏的订阅数。

可是个人数据量比这个大不少，而对数据的准确性要求就不那么高。因此首先要明确需求。其余答案有的说了用缓存，有的答案对比了count(*)、count(1)的区别，都很好，可是我认为仍是要看一下题主的场景。我根据我实际开发的经验总结以下几个方面，FYI。

数据量大/准确性要求低/请求量大

1. 这种场景通常是C端产品，好比上面说的获得APP的订阅数目，若是对一致性要求不高，能够直接在内存中使用缓存，用guava在内存中作一个缓存定时刷新便可，百万量级count(*)有缓存的频率还不至于有啥性能问题；
2. 可是内存内缓存有一个问题就是不一样服务器之间的缓存数量是不一致的，能够考虑用redis做为计数，通常这种场景是大多数同窗遇到的，简单粗暴搞定便可；
3. 用show table status。这个建议仍是不要用了，翻了下mysql 的doc，40%的偏差几率，碰上就有点大了呀。

TABLE_ROWS The number of rows. Some storage engines, such as MyISAM, store the exact count. For other storage engines, such as InnoDB, this value is an approximation, and may vary from the actual value by as much as 40% to 50%. In such cases, use SELECT COUNT(*) to obtain an accurate count.

数据量大/准确性要求高/请求量通常

这种场景通常出如今帐务上，好比有多少人打款。并且估计DAU在亿级别的公司可能才会遇到。这里最关键的问题仍是一致性的要求。在并发系统中，看看咱们用redis，咱们看看会出现什么样的一致性问题：

时间       A processor         B processor
T1         插入数据
T2                             1.redis#get计数器；2. 查询最新的N条数据
T3         redis#incr
复制代码

在T2的时间点的时候会出现数据不一致，B看到的是数据已经更新，可是数据库还没更新。咱们就在想，若是放到一个事务里面，就能够完美解决这个问题了呀。因为事务，innoDB不支持像MyISAM准确计数，解铃还须系铃人，因此咱们建一个计数表（count_table）+事务，解这个问题了。

时间         会话A                            会话B
T1         begin;
           在计数表中插入一条数据;
T2                                          begin;
                                            1. 读count_table；
                                            2. 查询最新的N条数据
                                            commit;
T3         更新conut_table;
           commit;
复制代码

在T1的时候，若是采用Mysql默认的事务隔离级别：读提交。由于T1事务尚未提交，因此插入的数据，B是读不到的，因此从逻辑上来讲是一致的。

数据量大/准确性要求高/请求量特别高

抱歉，没遇到过。若是你以为你遇到了，你的架构须要你从新design and review，相信我。

带条件count(*)

不少时候咱们的业务场景不是数据量多，而是条件复杂。这其实就是一个查询优化的问题了，和是否是count(*)没有关系，那么有如下两招经常使用，这个得具体问题具体分析了。好比时间维度能够加一个索引来优化；

select * from table_name where a = x and b = x;
复制代码

• 加索引
• 业务拆分

count性能比较

• count(primary key)。遍历整个表，把主键值拿出来，累加；
• count(1)。遍历整个表，可是不取值，累加；
• count(非空字段)。遍历整个表，读出这个字段，累加；
• count(能够为空的字段)。遍历整个表，读出这个字段，判断不为null累加；
• count(*)。遍历整个表，作了优化，不取值，累加。

结合mysql的一些索引查询知识，咱们能够大体得出以下结论。

建议直接使用count(*)。