OBJECT REFCOUNT 表示值对象被多少逻辑位置共享引用，是静态共享计数器而非访问频次统计；refcount=1为常态，>1说明复用（如小整数、Lua变量等），≠访问热度；判断高频访问应依赖命令统计、客户端埋点与性能分析。

OBJECT REFCOUNT 并不用于分析“引用频率”，它只返回当前 key 对应值对象被多少个地方共享引用，是一个静态计数器，不是时间维度上的访问频次统计。想靠 OBJECT REFCOUNT 判断某个公共字典 key（比如 dict:city 或 config:feature_flags）在线上被调用多频繁，这条路走不通。

refcount 的真实含义是“共享程度”，不是“访问热度”

Redis 中每个值对象（robj）都有一个 refcount 字段，它表示该对象在内存中被多少个逻辑位置持有着指针：

• refcount == 1：仅被数据库键空间引用（最常见情况）
• refcount > 1：说明该对象被复用，例如：
  • 小整数（0–9999）被多个键共用（Redis 预分配的共享对象）
  • 同一对象被 Lua 脚本、客户端输出缓冲区、事务队列等临时持有
  • 哈希表中的多个 field 指向同一个字符串值（极少见，需手动构造）
• refcount == 0：对象已标记为待释放，不会出现在正常查询中

真正反映“引用频率”的是访问行为本身

要评估一个公共字典 key（如 dict:province）是否高频访问，应关注其实际读取行为，而非 refcount：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• HGETALL dict:province 每执行一次，就是一次有效引用；但 refcount 可能始终是 1，毫无变化
• 即使 refcount 是 5，也只说明它被 5 个地方“同时持有”，不代表这 5 个地方都在高频读它——可能其中 4 个是长期缓存的 Lua 全局变量，1 个才是业务请求
• refcount 不随 GET/HGET 增长，只随内部对象共享逻辑变化（如创建、复制、入队）

优化公共字典结构的实用路径

针对高频使用的公共字典类 key，建议组合以下方式定位和优化：

• 用 redis-cli --hotkeys 或 INFO commandstats 看命令分布：确认 HGETALL、HGET 是否集中在少数几个 key 上
• 开启慢日志 + 客户端埋点：在应用层统计对 dict:* 类 key 的调用耗时与 QPS，识别真实热点
• 检查 encoding 和内存占用：用 OBJECT ENCODING dict:province 和 MEMORY USAGE dict:province 判断是否适合改用 ziplist（小数据）或拆分为分片 hash（大数据）
• 考虑降级策略：对只读、不变或低时效性字典，可预加载到各应用进程内存（如 Guava Cache），减少 Redis 单点压力

什么时候 refcount 值得一看？

仅在如下场景下，OBJECT REFCOUNT 有诊断价值：

• 怀疑存在异常对象共享（如 refcount 持续飙升，可能因 Lua 脚本未释放全局变量）
• 验证小整数是否被共享（SET age 25 后 OBJECT REFCOUNT age 很可能 >1）
• 配合 OBJECT IDLETIME 分析冷热分离：refcount=1 且 idletime > 86400，说明该 key 长期未被访问，可归档或清理