Redis 数据类型怎么选？5 种类型与适用场景一次讲清

Redis 数据类型选错，轻则命令写起来别扭，重则内存翻倍、统计出错。Redis 提供 String、Hash、List、Set、Sorted Set 五种核心结构，每种适合完全不同的业务。本文基于 Redis 7 验证，把这 5 种类型讲清楚，并给出一张「什么场景用什么」的选型表。看完你能根据业务特征直接拍板，不再把对象硬塞进 String 里用 JSON 凑合。今天这篇文章，编程狮就把这块讲透。如果你正纠结该用哪种结构存用户资料、排行榜或消息列表，下面这张选型表能让你少踩一半坑。

先看结论

一句话：单值用 String，对象用 Hash，要顺序用 List，要去重用 Set，要排名用 Sorted Set。

一、先弄清楚：为什么数据类型选错会出事

很多新手把所有数据都序列化成 JSON 塞进一个 String，表面能跑，其实埋了坑：更新一个字段要整体读改写，并发下容易丢更新；想按字段查询也没法用 Redis 的原生命令。

1.1 不同数据类型的内存与命令差异

同样存一份用户资料，Hash 哈希可以按字段单独读写，而 String 字符串存 JSON 必须整体操作。数据量大、字段更新频繁时，这个差异直接决定了性能和内存。

1.2 选型的三个判断维度

选型看三点：要不要按字段访问、要不要保序、要不要去重。先建立 Redis 的整体认识，建议读一遍 Redis 教程 的基础章节，再看下面每种类型。

二、String 与 Hash：单值与对象怎么存

String 字符串是最基础的类型，一个 key 对应一个值，适合计数器和缓存单个值。

# 文章阅读量自增
SET article:1:views 0
INCR article:1:views

Hash 哈希适合存对象，字段可以单独读写，不用整体序列化：

# 存用户资料，按字段更新
HSET user:1001 name "小明" age 18 city "杭州"
HINCRBY user:1001 age 1

如果对象字段多、又常改其中一两个，优先 Hash 哈希而不是 String 存 JSON。更深入的命令差异可以看 Redis 详解教程。

三、List 与 Set：有序与去重

List 列表是双向链表，头尾操作都是 O(1)，适合最新消息列表和简单队列。

# 最新 5 条评论进栈
LPUSH comments:post:1 "很赞" "收藏了" "转发了"
LRANGE comments:post:1 0 4

Set 集合自动去重且无序，适合标签和共同好友这类场景：

# 给文章打标签
SADD post:1:tags "redis" "缓存" "数据库"
# 求两篇文章的共同标签
SINTER post:1:tags post:2:tags

要顺序且允许重复选 List 列表，要唯一性选 Set 集合，这个分界很清楚。

四、Sorted Set 与横向选型

Sorted Set 给每个成员带一个分数，按分数排序，是排行榜的唯一正解。

# 游戏积分榜
ZADD leaderboard 95 "playerA" 88 "playerB"
ZREVRANGE leaderboard 0 9 WITHSCORES

把五种类型摆在一起：单值用 String，对象用 Hash，顺序用 List，去重用 Set，排名用 Sorted Set。缓存场景里，读多写少的小对象优先 Hash，大文本优先 String，避免无谓的结构开销。

4.1 三个最容易踩的坑

动手验证清单

下面的步骤帮你在本机确认每种类型的真实表现，避免纸上谈兵（命令基于 Redis 7，未在本机执行，请按你的版本核对输出）：

1. 前置安装：先装好 Redis 并启动服务，用 redis-cli ping 应返回 PONG，确认客户端能稳定连上服务端，这是后面所有操作的前提，连不上先查配置文件 bind 与 requirepass。
2. 运行写读：用 HSET user:1001 name "小明" age 18 写入用户对象，再用 HGET user:1001 name 读取单个字段；对比 String 存 JSON 必须整体读写的差异，体会 Hash 哈希的字段级优势。
3. 配置与检查：用 SADD 给文章加标签后用 SINTER 求两篇文章的共同标签，检查返回集合是否符合预期；用 ZADD 写入分数后 ZREVRANGE 取排行榜前 10，确认排序正确且带分数。
4. 验证选型差异：把同一份用户资料分别用 String 和 Hash 存一遍，用 MEMORY USAGE 对比两者内存占用；性能上字段多、更新频繁时 Hash 更省，单值小文本则 String 更直接，选错结构内存会悄悄翻倍。理解 Redis 数据类型的内存语义，比单纯背命令更重要，它直接决定你的缓存是省心还是埋雷。
5. 失败处理与排错：若出现大 Key 卡慢，把超大的 String 拆分为 Hash 多字段或分片；若排行榜分数相同导致乱序，给分数拼接时间戳做第二排序键；若误用 Set 当 List 丢失顺序，改回 List 列表。适用场景一句话：单值用 String，对象用 Hash，要顺序用 List，要去重用 Set，要排名用 Sorted Set，别再用 String 硬塞 JSON 凑合，存储选型的本质是按访问模式匹配 Redis 数据类型，而不是图省事全塞 String。

总结

Redis 数据类型没有绝对好坏，只有合不合适。String 字符串管单值，Hash 哈希管对象，List 列表管顺序，Set 集合管去重，Sorted Set 管排名。选错最常见的结果是用 String 存 JSON 导致整体读写、并发丢更新。

要点带走：

• 对象优先 Hash 哈希，按字段读写更省内存也更安全；
• 要排名必须 Sorted Set，别用 List 手动排序；
• 大对象拆字段，避免一个 Key 过大拖慢整个实例。

下一步可以结合业务把现有 String 缓存重构一遍，体会结构差异带来的性能变化。

延伸学习

这块知识系统补齐，按这个顺序来：

1. 内存管理同样关键，Redis 内存淘汰 讲了用完怎么办；
2. 想搞懂它为什么快，Redis 缓存入门 给了加速原理；
3. 持久化与性能的关系可看 Redis 持久化方式。

常见问题

Q：对象一定要用 Hash 而不是 String 存 JSON 吗？

A：不是必须，但字段多、常改局部时 Hash 更优。Hash 能单独读写字段、省去整体序列化，并发更新也更安全；只有整体读写、不关心内部字段时才用 String。

Q：排行榜用 List 排序行不行？

A：不推荐。List 列表没有分数概念，要排名得自己维护顺序，插入删除成本高。Sorted Set 自带分数排序和范围查询，是排行榜的标准做法。

Q：Set 和 List 到底怎么区分？

A：看要不要去重和保序。允许重复、要先后顺序用 List 列表；要求元素唯一、不关心顺序用 Set 集合。两者命令体系完全不同，选错会很难写。