明确需求
对这个问题有兴趣是源于一次开发中遇到要统计人数的需求。类似于“得到”专栏的订阅数。
但是我的数据量比这个大很多，而对数据的准确性要求就不那么高。所以首先要明确需求。其他答案有的说了用缓存，有的答案对比了count(*)、count(1)的区别，都很好，但是我认为还是要看一下题主的场景。我根据我实际开发的经验总结如下几个方面，FYI。
数据量大/准确性要求低/请求量大
- 这种场景一般是C端产品，比如上面说的得到APP的订阅数目，如果对一致性要求不高，可以直接在内存中使用缓存，用guava在内存中做一个缓存定时刷新即可，百万量级count(*)有缓存的频率还不至于有啥性能问题；
- 但是内存内缓存有一个问题就是不同服务器之间的缓存数量是不一致的，可以考虑用redis作为计数，一般这种场景是大多数同学遇到的，简单粗暴搞定即可；
- 用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(*)。
