优先用hash而非string存对象，因hash共享字段名并采用ziplist编码，实测省40%–60%内存；string存json重复存储引号、逗号等冗余字符，且无字段名复用与压缩机制。
直接结论：别用 String 存对象，优先用 HASH（配好 ziplist 阈值），Bitmaps 仅用于纯布尔状态场景。 String 存 JSON 是最省内存的错觉——它把字段名、引号、逗号全算进内存，而 HASH 的字段名共享+ziplist 编码实测省 40%–60%，Bitmaps 在签到/活跃等 0/1 场景下更是压倒性优势（125KB vs 16MB）。
为什么 String 存对象比 HASH 更费内存
String 类型存 {"name":"alice","age":28,"status":"active"}，每个 key 都重复带双引号、冒号、逗号、空格；Redis 不做任何去重或压缩。而同样数据用 HSET user:123 name alice age 28 status active，字段名 name/age/status 在 ziplist 中只存一份（底层共享前缀+紧凑字节数组），值也无额外符号。实测 10 万用户对象，String 占约 1.8GB，HASH（ziplist 编码）仅 720MB。
常见错误现象：OBJECT ENCODING user:123 返回 hashtable 而不是 ziplist，说明已退化，压缩优势消失。
- 字段数超
hash-max-ziplist-entries（默认 512）→ 退化 - 任一字段值长度超
hash-max-ziplist-value（默认 64）→ 退化 - 只改配置文件但没执行
CONFIG REWRITE→ 重启后失效
怎么让 HASH 真正保持 ziplist 编码
上线前必须调这两个配置，并验证编码类型：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
hash-max-ziplist-entries建议设为1024（字段固定且≤10个时，1024 安全；盲目设 2048 可能反而因内存对齐导致碎片上升） -
hash-max-ziplist-value建议设为128或256（按你最长字段值 × 1.5 估算，比如email平均 45 字节，取 64 就偏紧，128 更稳） - 改完立刻执行
CONFIG SET hash-max-ziplist-entries 1024和CONFIG SET hash-max-ziplist-value 128 - 再执行
CONFIG REWRITE持久化，否则重启丢配置 - 用
DEBUG OBJECT user:123确认 encoding 显示ziplist，且 serializedlength 接近预期
Bitmaps 什么时候该用、怎么用才不踩坑
Bitmaps 不是通用对象存储方案，只适合 ID 连续、状态二元（0/1）、批量统计的场景，比如每日签到、月活标记、开关灰度。
典型错误：拿 SETBIT user:flag:202605 123456789 1 存用户 123456789 的“是否 VIP”，结果发现用户 ID 稀疏（最大 10 亿但只用了 100 万），高位大量 0 占满内存。
- ID 必须密集连续：若用户 ID 是自增主键（1,2,3,…），Bitmap 合适；若是 UUID 或雪花 ID（如 9238472394823749），别用
- 避免单 key 过大：单个 Bitmap 超 500MB 会拖慢
BITCOUNT和BITOP，建议按天/按业务域分 key，如sign:20260527、active:202605 -
GETBIT和SETBIT是 O(1)，但BITCOUNT是 O(N) —— N 是整个字符串长度，不是 1 的个数；字段数百万时注意响应抖动
HGETALL 是性能黑洞，别当 SELECT * 用
HGETALL 在 ziplist 编码下需遍历解码全部字段，CPU 开销比 hashtable 还高；字段数 > 100 时，P99 响应可能突增 3–5 倍。
- 只读一个字段 → 无条件用
HGET user:123 name - 读多个已知字段 → 用
HMGET user:123 name age status，网络+解析开销可控 - 真要全量 → 先确认客户端支持流式解析（如 redis-py 的
hgetall返回 dict，但 Go 的redis.HGetAll可转 stream），且业务允许延迟 - 字段多又常全量？不如拆成
user:123（核心字段 HASH） +user:ext:123（扩展 JSON String），按需加载
最容易被忽略的一点：ziplist 编码虽省内存，但字段数增长后 CPU 解码成本非线性上升，不是“越小越好”，得在内存和 CPU 之间做显式权衡。上线前务必用真实数据压测 HGETALL 和 HMGET 的 P99 差异。
