InnoDB 的 COUNT(*) 必然慢，因其需按 MVCC 逐行判断可见性并累加，无法像 MyISAM 那样直接读取预存行数；Redis 缓存或汇总表可提速，但须妥善处理一致性、持久化及边界场景。
直接说结论：InnoDB 表上 COUNT(*) 慢是设计使然，不是你 SQL 写错了；靠 Redis 缓存或汇总表能显著提速，但必须处理好一致性、持久化和边界场景。
为什么 COUNT(*) 在 InnoDB 里必然慢
InnoDB 不像 MyISAM 那样在磁盘上存一个“总行数”字段——它得一行行读、逐行判断是否对当前事务可见（MVCC），再累加。哪怕你只查 COUNT(*)，优化器也只会选最小的索引树遍历（比如二级索引比主键索引小），但数据量到千万级后，IO 和 CPU 开销依然明显。
常见错误现象：COUNT(*) 查询从毫秒级变成几秒甚至超时；SHOW TABLE STATUS 返回的 Rows 字段波动大、误差常达 40% 以上，不能当真用。
- 这不是索引没建好导致的，即使全表有主键，
COUNT(*)仍需遍历索引叶子节点 - 加
WHERE条件后，如果条件字段无索引，就会退化成全表扫描，更慢 - 高并发下多个事务同时执行
COUNT(*)，各自走自己的 MVCC 视图，结果可能不同——这反而是正确行为，不是 bug
用 Redis 做实时计数：快但容易丢或错
适合对实时性要求高、允许短时误差的场景，比如页面 PV、用户在线数、点赞总数。
核心做法是：每次 INSERT/DELETE 同时操作 Redis 的 INCR/DECR，读取时直接 GET。
- Redis 必须开启 AOF +
appendfsync everysec，否则进程崩溃就丢计数 - 不要在应用层用“先 GET 再 INCR”这种两步逻辑，要用 Lua 脚本或原生命令保证原子性
- 如果业务有批量导入、逻辑删除（软删）、级联删除，这些路径容易漏掉 Redis 更新，导致漂移
- Redis 和 MySQL 主从延迟、网络分区时，计数会暂时不一致；若业务强依赖精确值（如库存、余额），就不能用这套
用汇总表做定时统计：准但有延迟
适合需要较高准确度、能接受分钟级延迟的聚合类需求，比如“今日订单数”“本月活跃用户”。
建一张独立的 stats_summary 表，按维度（如日期、状态、分类）存储预计算结果，用定时任务更新。
- 定时任务频率要按数据变更热度定：最近 7 天的数据每 15 分钟刷一次，3 个月前的每天凌晨跑一次即可
- SQL 示例：
INSERT INTO stats_summary (date, status, cnt) SELECT CURDATE(), status, COUNT(*) FROM orders WHERE created_at >= CURDATE() GROUP BY status ON DUPLICATE KEY UPDATE cnt = VALUES(cnt) - 注意退款、状态回滚等逆向操作——不能只靠正向累加，得把“减操作”也纳入统计逻辑，否则数字越积越大
- 汇总表本身也要加索引（如
(date, status)），否则连查汇总表都变慢
别忽略的细节：哪些情况 Redis 和汇总表都救不了
如果你的 count 需求带复杂条件（多表 JOIN、子查询、全文检索、JSON 字段匹配），那 Redis 和汇总表基本没法覆盖——它们只适合固定维度的简单聚合。
这时候真正该做的，是重构查询逻辑：
- 确认前端是否真的需要精确总数？很多分页场景其实只需要“有没有下一页”，可用
LIMIT n+1判断 - 把
COUNT(*)拆进业务流程：比如用户注册成功后，异步写入统计表，而不是每次点开页面都扫一遍用户表 - 检查执行计划：
EXPLAIN SELECT COUNT(*) FROM t WHERE x = ?，确保走了索引；没走的话，加覆盖索引比换方案更直接 - 超大冷表（如日志归档表）可考虑分区 +
information_schema.PARTITIONS估算，但仅限只读、低精度场景
最麻烦的不是技术选型，而是搞清业务到底要什么精度、能容忍多久延迟、出错时怎么兜底——这些决定了你该用 Redis、汇总表，还是干脆换个思路绕开 count。
