我是小耶，干运营半路出家的野生DBA——写功课只是为了我踩过的坑，你们别再踩了！
今天聊一个很多团队都会踩的坑：COUNT(*) 慢到影响业务了才发现。
很多开发在数据量小的时候觉得 COUNT(*) 是天经地义的统计方式，等表到了千万级，页面卡成PPT才开始找方案。其实问题的根源不在数据库，而在于我们对InnoDB机制的理解不够。
1 问题背景：为什么 COUNT(*) 会慢？
InnoDB 作为支持事务的存储引擎，需要保证多版本并发控制（MVCC）。同一时刻不同事务看到的数据行数量可能不同，因此无法像 MyISAM 那样用一个全局变量存储表行数。每次执行 COUNT(*)，InnoDB 必须选择一个最小的二级索引（如果存在），完整扫描该索引的所有叶子节点，累加计数。
以一张2000万行的用户表为例，主键索引约300MB，二级索引可能更小，但扫描仍然需要大量I/O。实测 SELECT COUNT(*) FROM users 耗时约2.3秒。
2 核心概念：COUNT(列)、COUNT(1)、COUNT(*) 的区别
COUNT(*)：统计所有行的数量，含NULL值。优化器会选择最小的非空索引扫描，性能最佳。COUNT(1)：效果与COUNT(*)完全一样，优化器会做相同处理。COUNT(主键)：同样扫描整个索引，性能与COUNT(*)几乎无差异。COUNT(非索引列)：需要扫描全表（聚簇索引），且忽略NULL值，性能最差。
结论：精确计数应直接使用 COUNT(*)，无需纠结用1还是主键。千万不要在生产环境用 COUNT(列) 替代。
3 优化方案与案例
3.1 方案一：EXPLAIN 估算（适合可接受误差的场景）
如果业务只需要大致数量（如“约1200万条”），可以使用 EXPLAIN 估算。执行 EXPLAIN SELECT * FROM table 输出的 rows 列是优化器基于统计信息估算的行数，不实际执行查询，毫秒级响应，误差通常在10%以内。
适用场景：后台仪表盘、数据趋势图、非财务类统计。若业务要求绝对精确，则不能用此方法。
3.2 方案二：维护专用计数表
创建一个计数表 table_counts（字段：table_name VARCHAR，row_count BIGINT），通过触发器在 INSERT / DELETE 时同步更新。查询时直接读该表，毫秒级返回。
优点：精确、速度快，不依赖缓存中间件。
缺点：写入性能略有下降（触发器额外开销），批量操作容易导致计数不准（例如批量导入1万条，触发器逐条执行效率差）。
改进：批量操作时，可先关闭触发器，手动更新计数表（UPDATE table_counts SET row_count = row_count + 批量行数），操作结束后再开启触发器。
3.3 方案三：使用 Redis 等缓存
在业务代码中，当插入或删除数据时，同步更新 Redis 计数器（INCR/DECR）。查询时直接读 Redis。
优点：极高吞吐，延迟微秒级，适合超高并发访问。
缺点：需要维护缓存与数据库一致，增加了架构复杂度，可能出现短暂不一致。
4 实践案例与性能对比
以一张2000万行的订单表（InnoDB）为测试环境，结果如下：
| 方法 | 耗时 | 精确度 | 并发影响 |
|---|---|---|---|
COUNT(*) |
2.3秒 | 精确 | 轻度增加I/O |
EXPLAIN |
0.001秒 | 估算 | 无 |
| 计数表 | 0.001秒 | 精确 | 写入略有下降 |
| Redis | 0.0005秒 | 精确 | 需额外维护 |
5 选型决策要点
- 业务对精确性的要求：财务、订单数量等必须精确，用计数表或缓存；运营大屏、趋势图可接受估算。
- 写入频率：写入极频繁（如日志表），更新计数表或缓存可能成为瓶颈，可改用定时任务异步计算。
- 运维复杂度：计数表方案需要管理触发器，Redis需要维护额外组件，小团队优先用计数表。
6 总结与建议
精确计数推荐 COUNT(*) 本身就够快；对大数据集或高频统计，优先使用计数表。根据业务场景选择合适方案，比单纯优化SQL更重要。
很多系统刚上线时数据少，什么都快；等数据量上去后，才发现 COUNT(*) 成为瓶颈。提前考虑计数优化，不是炫技，而是让业务在增长过程中能稳住体验。
小耶在手，SQL 不愁。
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
参考文献
[1] MySQL官方文档：InnoDB存储引擎，COUNT()优化说明
[2] 高性能MySQL（第4版），Baron Schwartz等
[3] 阿里云数据库性能优化最佳实践
本文基于MySQL 8.0.33，测试数据来自公开环境，结果仅供参考。
