HSET查单个字段更快，SET写整条数据更省网络；字段少且固定用HSET，动态多变或需原子替换用SET；LIST队列易丢消息，推荐STREAM；ZSET排行榜慎用浮点score；大SET内存开销大，慎用SMEMBERS。
字符串 SET 和哈希 HSET 存用户资料，哪个更快？
查单个字段（比如用户昵称）时，HSET + HGET 通常比 SET + JSON 解析快；但写入整条用户数据时，SET 一次存 JSON 更省网络往返。
常见错误是把所有字段塞进一个 SET 键里，结果每次改邮箱还得取、解析、改、序列化、再存——实际耗时翻倍，还容易出并发覆盖。
- 字段少且固定（如
name、age）、读写粒度细 → 用HSET user:123 name "Alice" age "28" - 字段动态多变（如用户扩展属性、标签列表）、或需原子性整体替换 → 用
SET user:123 '{"name":"Alice","tags":["vip"]}' -
HGETALL返回全部字段，但网络开销大；HGET单字段才是哈希的真正优势点
用 LIST 做消息队列？小心阻塞和丢消息
LPUSH + BRPOP 看似能当队列用，但没确认机制、不支持重试、消费者崩溃就丢数据。真要轻量级队列，优先考虑 STREAM。
性能上，LIST 的 LPOP 是 O(1)，但 LRANGE 查历史是 O(N)；而 STREAM 的 XREAD 是 O(M)，M 是返回条数，天然适合游标分页。
- 仅临时缓存最近 N 条日志（如操作审计）→
LPUSH log:recent "op=login"+LTRIM log:recent 0 99 - 需要消费组、ACK、失败重投 → 必须用
XADD stream:order ...+XGROUP CREATE -
BLPOP超时后返回 nil，容易被当成“无任务”跳过，实际可能只是刚好空窗——得配合监控延迟指标
ZSET 排行榜卡顿？别只看 ZRANGE 复杂度
ZRANGE rank:game 0 99 WITHSCORES 看似 O(log N + M)，但当 N 达千万级、M 固定为 100，瓶颈常在内存带宽和网络序列化——特别是 score 是浮点数时，Redis 序列化开销比整数高 2–3 倍。
更隐蔽的问题是：用时间戳当 score 做“最新 TOP100”，一旦有大量写入，zset 的跳跃表会频繁调整层级，CPU 毛刺明显。
- 纯分数排序（如积分榜）→ score 用整数，避免浮点；key 设计为
rank:game:score - 按时间倒序取最新（如热搜）→ 改用
STREAM+XREVRANGE，天然按插入顺序索引，不依赖 score 计算 - 需要分页（第 10001–10100 名）→
ZRANGE跳过前 10000 项仍是 O(N)，此时应预生成“段缓存”，比如每万名为一个 key
集合 SET 去重和交集，内存比想象中吃得多
一个含 100 万个字符串的 SET，实际内存占用可能是原始字符串总长的 3–5 倍——因为 Redis 用 intset（小整数）或 hashtable（通用），后者每个元素额外带指针、hash 桶、rehash 预留空间。
如果只是判断“用户 A 是否在黑名单”，SET 没问题；但要是存“每个商品的百万级 SKU ID”，就得警惕：SISMEMBER 是 O(1)，可 SMEMBERS 全量拉取会打爆客户端内存。
- 成员稳定、总量可控（SADD black:user 1001 1002
- 成员超 50 万 或 含长字符串（如 UUID）→ 改用布隆过滤器（
BF.ADD，需 RedisBloom 模块）省 80%+ 内存 - 求多个集合交集（
SINTER）时，Redis 会自动选最小集合做基准遍历——所以别把大集合放第一个参数，否则白耗 CPU
最常被忽略的是：SET 不保证插入顺序，也不支持范围查询。以为能靠 SSCAN 分批处理就安全，其实 scan 游标不保证一致性，两次 scan 间增删可能导致漏或重复。
