矢锋1. 先分清count的三种写法，别被“效率更高”的传言带偏
很多人在MySQL里用count函数，完全凭肌肉记忆写。count(*)、count(1)、count(字段名)这三种写法在面试题里被反复讨论，网上说法也是五花八门，什么“count(1)比count()快”、“count(字段)不走索引”、“count()最快因为专门优化过”——我见过最有意思的说法是，有人用count(id)因为觉得“主键肯定性能最好”。这些说法半对半错，如果搞不清楚本质，线上出了问题很难定位。
先看这三种写法的核心差异到底在哪：
count(*)：统计的是结果集的行数，包含值为NULL的行。count(1)：统计的也是结果集的行数。这里的1是一个常量表达式，不涉及任何字段读取，同样包含值为NULL的行。count(字段名)：统计的是该字段非NULL值的个数。只要这一行的指定字段是NULL，就不会被计入总数。
这个差异非常重要。比如一张订单表中，pay_time允许为空，你想统计“已支付订单数”，如果写成count(pay_time)，结果会把大量未支付订单漏掉，因为未支付订单的pay_time是NULL。但如果你写成count(*)配合WHERE pay_time IS NOT NULL，才可以拿到预期结果。
那网上说的“count(1)比count(*)快”到底成立吗？从MySQL 5.7和8.0的实际执行计划来看，在没有WHERE条件的情况下，count(*)和count(1)执行的扫描方式几乎完全一致，优化器会把他们当成等价写法处理。我在MySQL 5.7.29和8.0.28上分别用500万行的测试表跑过，两种写法的执行时间基本在误差范围内波动，没有稳定的性能差异。真正需要区分的是count(字段)，由于要额外判断NULL，加上可能涉及回表，很多时候反而更慢。这句结论已经经过大量DBA验证，可以放心记下来。
但注意，我说的是“在没有复杂条件的情况下”。一旦加上了WHERE、JOIN或者GROUP BY，count的语义和执行路径就会发生显著变化，这个下面分场景拆开讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. MyISAM和InnoDB的count差异：从“秒回”到“慢如牛”的真实原因
很多从MyISAM时代走过来的开发者，都有过这样的疑惑：同样的SELECT COUNT(*) FROM t，在MyISAM表里瞬间返回，到了InnoDB表里却扫描半天。这里面的原因，不是InnoDB不够努力，而是两者的存储结构决定的。
2.1 为什么MyISAM的count(*)能直接“秒回”
MyISAM引擎把每张表的行数作为元数据单独存了起来。执行SELECT COUNT(*) FROM t的时候，MyISAM只需要直接读取这个行数记录，时间复杂度是O(1)，数据量再大也不会慢。这个特性的前提是：表没有WHERE条件，统计的是全表行数。
这也解释了为什么MyISAM一旦加上WHERE条件，同样会慢下来——因为元数据里只存了总行数，没有存“销售状态为已支付的行数”，它还是得老老实实扫描数据。所以“MyISAM的count快”这个结论，必须限定在无条件的全表统计场景。
2.2 为什么InnoDB不存行数
InnoDB不保存精确行数的根本原因，是它的多版本并发控制机制。同一张表，不同事务在不同的隔离级别下看到的行数可能不一样——你的事务A还没提交，事务B已经插入了一条新数据，那B看到的行数是10001，A看到的还是10000。如果引擎层面像MyISAM一样缓存一个总行数，那这个行数该以哪个事务的视角为准？在多并发下很难维护。
所以InnoDB选择了另一条路：每次执行count(*)时，实时根据当前事务的可见性判断哪些行属于当前视图，逐行累加。这个设计保证了数据一致性，但代价就是——如果表里没有可用的索引来加速统计，InnoDB只能走全表扫描。5.7版本里，InnoDB会对全表扫描做一项优化，扫描最小的辅助索引而不是聚集索引，来减少需要读取的数据量。但要明白，这个优化只是减少IO开销的“省力措施”，不等于跳过扫描，表很大一样会很慢。
2.3 实际场景中的性能表现
拿我实际遇到过的一个业务场景举例，一张流水表有3000万行，没有走WHERE条件直接SELECT COUNT(*) FROM 流水表，在MySQL 5.7的InnoDB下跑了接近30秒。这个结果是意料之中的，因为InnoDB要扫数据页，还要经过缓冲池、内存拷贝，最终才累加出总行数。
但这类统计如果出现在线上用户请求的接口里，30秒的等待是完全不能接受的。所以，与其纠结“为什么InnoDB这么慢”，不如把精力放在两个方向上：一个是设计层面规避高频全表count，另一个是能走索引就尽量走索引。
一个常见的误解是：“我给表加一个索引，count就快了”。这话只对了一半。如果你执行的是SELECT COUNT(*) FROM 订单表 WHERE status = 1，那么只要status上有索引，统计的范围会大幅缩小，确实会快很多。但如果你执行的是无条件的SELECT COUNT(*) FROM 订单表，那加不加索引效果都不大，因为InnoDB还是要遍历索引节点或者数据页，只是从扫主键索引换成了扫二级索引而已。缩小表体积或者做分区，才是这个场景下的真正解法。
3. 一条count(*)在InnoDB里到底扫描了什么：从执行计划看优化器选择
想真正掌握count函数，最好把它的执行过程“可视化”一遍。很多教程直接讲结果，但忽略了过程，结果读者只背住了结论，一旦遇到稍微不一样的场景就懵了。我建议你以后在排查count性能问题时，先做的一件事就是：EXPLAIN，看优化器到底选了什么索引。
3.1 为什么优化器会扫描“最小”的索引
先建一张简单的测试表：
sql复制CREATE TABLE `t_order` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`user_id` bigint(20) NOT NULL,
`status` tinyint(4) NOT NULL DEFAULT '0',
`create_time` datetime NOT NULL,
`amount` decimal(10,2) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_user_id` (`user_id`),
KEY `idx_create_time` (`create_time`)
) ENGINE=InnoDB;
我往里面插入了约200万行数据，然后执行：
sql复制EXPLAIN SELECT COUNT(*) FROM t_order;
执行计划里显示的是一个二级索引idx_user_id。原因是在InnoDB中，主键索引的叶子节点存储的是整行数据，而二级索引的叶子节点只存储索引列和主键值。同样读一个数据页，二级索引能装下更多的索引条目，扫描完整个索引需要读取的数据页数量更少，IO成本更低。所以MySQL优化器在做全表count时，会倾向于选一个体积最小的辅助索引来扫描。
这个“最小”往往取决于索引列的长度。比如你有一个char(200)的二级索引和一个int类型的二级索引，优化器大概率会选择后者，因为它的索引树更矮、叶子节点更紧凑。
3.2 带条件时索引可能失效的几种典型情况
很多慢查询不是count函数本身慢，而是WHERE条件根本没用上索引。最典型的几种：
- 在索引列上做了函数运算：
WHERE DATE(create_time) = '2024-01-01'，优化器无法直接把create_time上的索引用于范围定位，通常需要全表扫描。 - 隐式类型转换：
WHERE user_id = '123456'，如果user_id是数值类型，MySQL可能可以自动转换；但如果是反过来的情况，字段是varchar、传入的是数值，索引可能失效。 - 前导模糊匹配：
WHERE user_name LIKE '%张%'，这个无法走索引前缀匹配。
我遇到过的最痛的一次排查：业务在订单表上统计某天付款订单数，SQL长这样：
sql复制SELECT COUNT(*) FROM t_order WHERE DATE(pay_time) >= '2024-06-01' AND DATE(pay_time) < '2024-06-02';
当时这张表已经2000万行，这个查询跑了快40秒。原因就是pay_time字段上套了DATE()函数，索引无法用于范围扫描。改成WHERE pay_time >= '2024-06-01 00:00:00' AND pay_time < '2024-06-02 00:00:00'之后，走了idx_create_time索引，查询时间降到100毫秒以内。差别巨大，函数的威力在索引面前真的不容小觑。
3.3 优化器选错索引怎么办
偶尔会遇到优化器没有选到最优索引的情况，比如两个索引的区分度差异很大，但优化器估算成本时发生了偏差。这时候不建议直接写FORCE INDEX硬性指定，因为随着数据分布变化，硬编码的索引可能在未来不再是好的选择。更稳妥的做法是：
- 更新统计信息：
ANALYZE TABLE t_order;，让优化器基于最新数据重新估算。 - 改写SQL，让条件更利于优化器判断。
- 检查是否由于多表JOIN导致驱动表选择不当，必要时调整关联顺序。
另外补充一句：8.0版本里加入了EXPLAIN ANALYZE，可以真实执行SQL并返回每一行消耗的时间，定位慢查询时比普通EXPLAIN更直观。我在分析慢count语句时用过几次，它能把“到底慢在哪个步骤”直接暴露出来，强烈推荐用起来。
4. COUNT(DISTINCT)和GROUP BY场景下的性能陷阱与实测数据
上面讲的都是简简单单数总数，但实际业务里问得更多的其实是“去重统计”，比如统计某天的活跃用户数。这时候用到的是COUNT(DISTINCT user_id)。
4.1 COUNT(DISTINCT)为什么会突然变得特别慢
COUNT(DISTINCT user_id)的执行逻辑是：先按user_id排序或哈希分组，再去重计数。如果user_id上刚好有索引，MySQL可以通过扫描索引来保证有序，优化器通常会用索引扫描配合临时表去重。但如果没有合适的索引，MySQL就需要建立临时表，甚至可能触发磁盘临时表，性能一下子就垮了。
我做过一次实际测试，同样是一张2000万行的用户行为表，统计指定日期范围的不重复用户数（约300万日活）：
- 有
idx_user_id的情况下：COUNT(DISTINCT user_id)执行时间约2.3秒。 - 去掉这个索引之后：同样的SQL执行时间飙升到18秒左右，额外出现了
Using temporary。
可以看到，差距非常大。但这2.3秒对在线接口来说依然不可接受，所以在线上做这种统计时，我一般不直接查业务表，而是用离线表或者汇总表解决。
4.2 用COUNT(DISTINCT)和GROUP BY配合时的一个隐蔽问题
还有一类情况特别容易踩坑：GROUP BY + COUNT(DISTINCT ...)组合使用时，很多人没想清楚GROUP BY的字段是否会影响统计范围。
举个例子：
sql复制SELECT province, COUNT(DISTINCT user_id)
FROM user_login_log
WHERE login_date = '2024-06-01'
GROUP BY province;
这个SQL统计的是每个省的去重用户数，注意如果同一个用户当天在多个省份登录过，它会被多个省份各自统计一次。全局去重总数并不等于各省份数量之和。对于要出报表的场景，这个逻辑偏差很大，但SQL引擎不会报错，也不会提示你，只能靠业务方自己判断口径。我在做数据核对时吃过这个亏，后来凡是涉及去重统计，都会先跟业务确认清楚到底是“全局去重”还是“分组内去重”。
4.3 替代方案：用DISTINCT + JOIN或UNION是否更优
有人在去重统计时习惯用SELECT DISTINCT先把结果集拿出来，再在应用层数个数。这种写法在小数据量下没什么问题，但数据量一大，应用层要承载的行数会非常高，内存和网络开销都很大。COUNT(DISTINCT)虽然也要建立临时表做去重，但它在服务端就直接把计数结果返回了，不用把明细数据传输到应用层，整体效率通常更高。
用UNION去重再套一层COUNT(*)的写法也见过不少：
sql复制SELECT COUNT(*) FROM (
SELECT user_id FROM a UNION SELECT user_id FROM b
) t;
这个做法的逻辑没错，但UNION自带去重且在多个结果集合并时会有额外排序或哈希的成本，性能通常不如直接在单表上做聚合。除非业务本身就需要跨表去重，否则不推荐为了“去重”而引入UNION。
5. 几百万行以上还想频繁count？这几个方案能救急
如果表已经几百万甚至几千万行了，任何在线业务都撑不住频繁的全表count。与其硬扛，不如在设计上绕开。下面聊几个我自己验证过、真实落地过的方案，以及各自适用和不适用的情况。
5.1 用EXPLAIN的估算行数代替精确count
MySQL优化器在解析SQL时，会根据统计信息和索引基数估算可能扫描的行数。EXPLAIN输出里有一个rows字段，这个值虽然不是精确的行数，但在很多只需要“量级参考”的场景下完全够用。
比如后台管理系统要展示一张表的规模，精确值是100万还是95万，对用户来说感知并不强。但如果你直接SELECT COUNT(*)，可能每次请求都要扫几秒钟。改成EXPLAIN SELECT ...，代价可以忽略不计。
不过要注意，rows是优化器基于抽样统计做出的估算，可能存在偏差。尤其当表数据频繁更新、统计信息来不及刷新时，偏差可能达到几倍甚至更高。所以这个方法只能用在“不要求精确”的场景。
- 适合：列表展示总数、后台卡片指标、数据看板的大数字。
- 不适合：财务对账、订单总数核对、精确分页。
5.2 增加独立的计数表，用事务保证一致性
很多团队选择用Redis的INCR来维护计数，但Redis和MySQL之间缺乏统一事务，一旦二者数据不一致，排查起来很痛苦。如果你对数据一致性要求比较高，可以建一张计数表，在业务事务里同更新。
举个例子，每新增一条订单，在同一个数据库事务里执行：
sql复制INSERT INTO t_order (...) VALUES (...);
UPDATE t_order_count SET cnt = cnt + 1 WHERE stat_date = '2024-06-01';
查询时直接读t_order_count即可。这个方案的好处是：计数精准、带事务保护、不需要扫描业务表。坏处是业务逻辑侵入性强，删除、更新操作也需要同步维护计数器，稍不留神就会漏更新。我见过因为漏了更新条件导致计数表严重失真的案例，所以如果选这个方案，务必对每一条会影响计数的SQL都做review。
也可以考虑用触发器来维护计数表，应用层不需要改动，性能和一致性也稳定。但触发器会增加写入链路的开销，还要小心死锁问题。我一般只在低频写入、高频计数的表上使用触发器方案。
5.3 使用汇总表或者物化视图思路
如果统计口径是常规的排序维度，比如“每天的用户数”、“每小时的订单数”，完全可以建一张汇总表，由定时任务（如每隔5分钟）按时间窗口聚合原始数据，把结果写入汇总表。查询端只查汇总表，不再触达明细表。
这里有个细节：定时任务最好带幂等性。例如按统计日期删除旧汇总结果再重新计算，防止任务重复执行导致数据翻倍。我在实践里会用INSERT ... ON DUPLICATE KEY UPDATE或先删后插的方式保证结果准确。
这个方案的优点是不侵入业务写入链路，也比较容易追溯和修复，缺点是统计延迟取决于定时任务的调度间隔，适合分钟级甚至小时级延迟都可接受的场景。
5.4 如果必须精确count，尽量缩小扫描范围
有些场景绕不开精确统计，比如订单量对账。这时候你不能用估算，也不能靠缓存，只能老老实实查数据库。但可以通过条件限定减少扫描规模，比如：
- 按时间分区表，只统计最近一个月的分区，而不是全表。
- 增加“归档表”机制，将历史数据定期迁移到冷表，热表只保留近期数据，减小热表的体量。
- 在查询条件上尽量使用等值条件或范围条件，配合二级索引。
我参与过的一个订单系统，就通过“按月分区+历史归档”的方式，把在线订单表从4000万行降到了400万行左右，这张表的count查询从10秒级别降到了百毫秒级别。效果立竿见影。
5.5 高并发场景下的计数设计
如果同一秒内有大量并发请求触发count，就算走了索引，也会给数据库带来很大压力。比如秒杀活动的商品详情页要展示“已抢购人数”，如果没有计数服务，全靠count查询，数据库连接很容易被打满。
这种场景我建议把计数完全放到Redis，但不要只依赖Redis。可以采取这样的策略：
- 用Redis的
INCR或HINCRBY维护实时计数。 - 定时把Redis计数同步到MySQL计数表，作为对账用的持久化数据。
- 极端情况下，即使Redis短暂宕机，计数出现误差，也要保证最终一致。
需要特别注意一个坑：不要把Redis当成唯一数据源，Redis是内存数据库，重启或淘汰策略可能造成计数丢失。线上只能把它当作加速缓存层，底层必须有持久化数据兜底。
5.6 8.0下的新可能性：直方图带来的优化
MySQL 8.0引入了直方图功能，它会在没有索引的列上收集数据分布信息，让优化器对查询条件的行数估算更准确。虽然直方图本身不直接加速count，但能帮助优化器选出更合适的执行计划，避免因为估算偏差选了差的索引。
我在一张日志表上给某个枚举列建过直方图，之后一些等值查询的rows估算明显更接近实际数据分布，执行计划确实更合理。对于线上不方便随便加索引的场景，值得一试。方式：
sql复制ANALYZE TABLE t_order UPDATE HISTOGRAM ON status WITH 4 BUCKETS;
生成之后可以用SELECT * FROM information_schema.COLUMN_STATISTICS WHERE TABLE_NAME='t_order'\G;查看直方图详情。它并不是所有慢count问题的银弹，但在索引策略受限的场景里多了一个调优手段。
6. 我在真实业务中总结的几条count使用建议
写了这么多，最后聊聊我在不同项目里沉淀下来的几条实操经验。这些建议不一定每个都适合你的业务，但放在一起，能规避掉大部分线上count性能问题。
第一，团队内部统一约定：能用count(*)就不用count(字段)。count(字段)容易在语义上产生二义性，尤其是字段可空的时候。如果确实需要统计非空数量，一定要在注释里写清楚原因，避免后来维护的人误改。
第二，不要在事务里做高频count。事务会持有连接和锁资源，长事务本身就是性能隐患，再叠加count大表，很容易拖垮连接池。我做活动统计时，会强制把count查询放到只读实例上。
第三，习惯性先看执行计划再调优。我见过很多同事一遇到count慢就去改SQL写法，从count(*)改成count(1)，发现没效果，再改成count(id)，还是没效果。实际上问题根本不在函数选型，而在于WHERE条件没走索引。早一步EXPLAIN，就能少走很多弯路。
第四，对于任何超过千万行的表，不要在需求评审时轻易承诺“可以实时count”。要么做汇总表，要么做缓存，要么限制时间范围。这是技术风险和业务预期管理的问题，提前说明比上线前救火要省事太多。
第五，应用层加缓存时，一定要考虑缓存失效后的穿透问题。某次大促期间，营销页面的pv计数缓存过期，一瞬间的并发count打到底层数据库，直接把连接池打满。后来我们给计数缓存设置了合理的过期时间，并加了互斥锁，防止大量请求同时回源数据库。
我自己在接手一个接手过count慢查询的旧系统时，通常会先收集一周的慢查询日志，按SQL指纹聚合出count类语句的执行次数和平均耗时，排个序，优先处理那些“执行次数多且耗时高”的语句。很多问题是隐藏的，不做日志分析，根本发现不了有些数仓同步任务反复在低效地count全表。
最后再分享一个小技巧：有时候业务方要的只是一个“看起来足够新”的数字，而不是精确到个位数的值。这时候可以用定时任务每10分钟更新一次汇总表，查询端读到的就是“截止到最近10分钟”的数据。对于绝大多数非对账类需求，这个精度已经足够了，却能让数据库压力下降一个数量级。先搞清楚“精确值”和“够用的值”之间的差距，是MySQL执行效率优化里最容易被忽视的一环。