直接缓存count(*)结果不可靠，应通过双写+定时校准机制维护近似实时计数器：写操作用incrby/decrby同步更新redis计数，再辅以低频sql校准兜底，并规避序列化、热key等陷阱。
直接缓存 COUNT(*) 结果是可行的，但不能简单地“查一次塞进 Redis 就完事”——容易脏、不准、漏更新，尤其带 WHERE 条件时更危险。核心思路是：**把统计逻辑从数据库里搬出来，用业务可控的方式维护一个近似实时的计数器**。
为什么不能只靠 Redis 缓存 COUNT(*) 原始结果
因为 COUNT(*) 本身不带条件，但业务几乎从来不是真要“全表总数”。比如“待审核订单数”“近7天活跃用户”，这些都带 WHERE 过滤。Redis 里存一个固定值，一旦数据增删改没同步，立刻错；而每次写操作都去重算一遍 COUNT(*)，又回到慢查询的老路。
常见错误现象：
- 运营后台显示“今日新增用户 120”，实际 DB 里是 187 —— 缓存没更新或更新延迟太久
- 用户刚下单，订单列表刷新后数量+1，但“待支付订单总数”缓存还是旧值，等 5 分钟才变
- 用
INCRBY手动维护计数，但事务失败时没回滚，计数永久偏差
推荐方案：双写 + 校准机制（Hyperf 中落地）
不依赖单次查询结果，而是让写操作驱动计数变更，再辅以定时校准兜底。Hyperf 的协程特性让这个过程轻量可控。
实操建议：
- 在订单创建成功后，用
$redis->incr('order:status:unpaid')同步加 1；取消订单时用decr减 1 - 所有涉及状态变更的写路径（如支付成功、审核通过）都补上对应
INCRBY/DECRBY操作，放在事务提交后（可用 Swoole 协程延时或 defer） - 配置一个低频定时任务（如每小时），执行
SELECT COUNT(*) FROM orders WHERE status = 'unpaid'，与 Redis 当前值比对；差值超过阈值（如 >5）就全量重置SET order:status:unpaid {actual} - 避免用
KEYS order:*扫描，所有计数 Key 必须有明确命名规范，例如stat:order:unpaid、stat:user:active:7d
带条件的 COUNT 怎么缓存？别硬塞 WHERE 到 Key 里
像 SELECT COUNT(*) FROM user WHERE dept_id = ? AND is_deleted = 0 这种，参数多、组合爆炸，Key 很难设计。硬拼成 count:user:dept_123_notdel 会导致缓存碎片化、命中率低，还容易因参数顺序/空格等导致重复 Key。
更稳妥的做法：
- 把条件抽象为“维度标签”，例如
dept_id和is_deleted是两个独立维度，用 Hyperloglog 或 Bitmap 存储用户 ID 集合，再做交集计数（适合 UV 类场景） - 对高频固定条件，建专用统计表（如
user_dept_stats），用INSERT ... ON DUPLICATE KEY UPDATE维护，查询走主键，毫秒级 - 如果必须用 Redis，优先选
HASH结构：Key 是stat:user:dept，Field 是dept_id，Value 是当前计数，避免字符串 Key 泛滥
Hyperf 里最容易被忽略的坑：序列化和热 Key 冲突
很多人用 @Cacheable 注解缓存 count 结果，但没注意 Packer 默认是 PhpSerializerPacker，而 INCR 返回的是整数，GET 出来却是字符串，类型不一致会引发判断错误。
还有更隐蔽的问题：
- 所有写操作都走同一个 Redis 连接池，
INCR高并发时变成串行瓶颈 —— 要确认pool.max_connections足够，且没被其他缓存占满 - 用
CoroutineMemoryDriver缓存“本次请求内已查过的 count 值”，避免同个请求里多次GET同一个 Key，但别误用它替代 Redis 全局计数 - 校准任务如果也读同一个 Redis 实例，高峰期可能拖慢主业务 —— 建议校准走只读从库或单独缓存池
真正难的不是“怎么存”，而是“什么时候更新、谁负责更新、出错了怎么发现”。缓存 count 的一致性，永远比性能更值得花时间设计。
