明确需求
对这个问题有兴趣是源于一次开发中遇到要统计人数的需求。类似于“得到”专栏的订阅数。
但是我的数据量比这个大很多,而对数据的准确性要求就不那么高。所以首先要明确需求。其他答案有的说了用缓存,有的答案对比了count(*)、count(1)的区别,都很好,但是我认为还是要看一下题主的场景。我根据我实际开发的经验总结如下几个方面,FYI。
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(*)没有关系,那么有以下两招常用,这个得具体问题具体分析了。比如时间维度可以加一个索引来优化;
select * from table_name where a = x and b = x;
结合mysql的一些索引查询知识,我们可以大致得出如下结论。
建议直接使用count(*)。
本文分享自 Leetcode名企之路 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!