COUNT(*)在大表上慢因需全表/索引扫描、MVCC可见性判断及可能触发filesort或临时表；加索引通常无效，除非覆盖索引且字段非NULL；推荐采样、缓存或辅助表双写。
为什么COUNT(\*)在大表上特别慢
因为数据库默认要扫描全表或全索引才能确认行数，哪怕加了主键或索引，COUNT(*) 仍可能触发 Using filesort 或临时表，尤其当表有上亿行、且没有覆盖索引时。InnoDB 的 MVCC 特性还会让每次 COUNT 都得做可见性判断，不是简单读个元数据。
常见错误现象：EXPLAIN 显示 type=ALL 或 rows 接近表总行数；监控里 Handler_read_next 暴涨；接口超时集中在统计页。
- 别指望加索引就能加速
COUNT(*)—— 大多数情况下没用，除非是覆盖索引且字段非 NULL -
COUNT(1)和COUNT(*)在 MySQL 8.0+ 几乎无差别，别迷信“COUNT(1)更快”这种过时说法 - 如果业务允许误差 ≤1%，优先考虑采样或缓存，而不是硬扛全表扫描
用辅助表维护实时行数（适合写少读多）
核心思路：把“查总数”变成“查单行”，用事务保证一致性。不依赖触发器（易出错），改用应用层双写或 binlog 解析同步。
使用场景：用户中心、订单状态统计、后台管理页的列表总数展示 —— 这些地方对“精确到个位”有强要求，但更新频率不高（比如每分钟新增
- 建一张
table_counts，字段为table_name（主键）、row_count、updated_at - INSERT/DELETE 时，在同一事务中更新
row_count：例如UPDATE table_counts SET row_count = row_count + 1 WHERE table_name = 'orders' - 避免用
SELECT COUNT(*) FROM orders初始化 —— 改用SELECT TABLE_ROWS FROM information_schema.TABLES（注意：该值是估算，仅用于初始化） - MySQL 5.7+ 可用
INSERT ... ON DUPLICATE KEY UPDATE简化逻辑，避免先查后更
Redis 缓存 COUNT 结果（适合容忍短时误差）
把“精确计数”降级为“准实时计数”，用 Redis 的原子操作扛住高并发读，同时控制写延迟。关键不是缓存结果本身，而是定义好失效边界。
常见错误现象：缓存未及时更新导致后台看到“0 条数据”；多个服务实例并发写入造成计数漂移；Redis 宕机后直接 fallback 到 DB 导致雪崩。
- 用
INCRBY/DECRBY更新计数，不要用GET + SET—— 后者有竞态 - 设置合理过期时间（如
EX 60），但不要依赖它自动刷新；失效后走异步任务重算，而非同步查 DB - 缓存 key 命名带业务上下文，例如
count:orders:status:paid，别只用orders_count - 务必加降级开关：当 Redis 不可用时，返回本地内存里的上一个已知值（比如用
ConcurrentHashMap存最近一次成功值），而不是直连 DB
什么时候该放弃 COUNT(\*)，换查询逻辑
很多所谓“总数需求”，其实根本不需要精确数字。前端分页组件、搜索结果提示、运营看板，往往只需要“是否还有下一页”或“数量级感知”。这时候硬优化 COUNT(*) 是南辕北辙。
性能影响明显：一个 COUNT(*) 耗时 800ms，而 SELECT id FROM orders ORDER BY id DESC LIMIT 1 OFFSET 9999 只要 12ms —— 因为后者能用索引跳过大部分数据。
- 分页总数？改用“是否有第 N+1 页”：查
SELECT 1 FROM table WHERE condition LIMIT 1 OFFSET N - 搜索结果提示“约 23,000 条”？用
EXPLAIN的rows字段 + 抽样修正，误差可接受 - 需要按条件动态聚合？提前物化视图或用 ClickHouse 做 OLAP 层，别在主库硬算
- 千万行以上表，任何带
COUNT(*)的线上接口，都应默认视为潜在慢查询，进 slow log 监控
真正难的不是选 Redis 还是辅助表，而是判断业务到底需不需要那个“精确数字”。这个判断一旦错了，后面所有优化都在给错误目标打补丁。
