Redis里那些Key值的小技巧，居然能帮你省不少存储空间，也挺值得一试的

综合自多位Redis实践者的经验分享和博客文章，如“Redis实战经验”、“老王的Redis笔记”等）

Redis这个内存数据库，速度快是没得说，但内存毕竟比硬盘金贵多了，有时候数据量一大，看着内存噌噌往上涨，心里难免发慌，除了升级硬件，我们在日常使用中，通过一些很实在的、针对Key本身的小技巧，就能省下不少空间，这些方法不涉及高深莫测的原理，上手就能用,效果立竿见影。

第一招：给Key起个“短小精悍”的名字。

这可能是最简单、最容易被忽略，但累积起来效果却非常显著的一招，很多人写代码时，为了让Key的意义更明确，会起非常长的名字，user_profile_cache_for_user_id_12345，看起来是清晰了，但这个Key本身就已经占了快40个字节，在Redis中，每个Key都是需要占用内存的，Key越长,占的空间自然就越大。

那怎么办？缩写呗，把上面那个长长的Key改成 u:p:12345（user:profile:12345），意思差不多都能懂，但长度直接从40字节缩短到了10字节以内，如果一个系统里有成千上万个这样的Key，省下来的空间就非常可观了，缩写要讲究个度，得保证你和你的团队成员都能看得懂，别为了省空间搞得自己也忘了是啥意思，那就本末倒置了,最好能有一个统一的命名缩写规范。

第二招：活用前缀和冒号来“归类”，但别过度。

Redis官方推荐使用冒号 来给Key划分层次，user:1000:profile, user:1000:orders，这样做的好处不仅仅是看起来整齐，更在于管理方便，可以用 KEYS user:1000:* 这样的模式来批量操作相关Key。

从节省空间的角度看，这种结构也有妙用，它允许我们利用一个叫做“共享对象”的Redis内部优化，简单说就是，如果很多Key拥有共同的前缀（比如user:1000:），Redis在内部可能会只存储一份这个前缀，然后让多个Key共享它，而不是每个Key都存一份完整的长字符串，这尤其在你使用了类似 HMSET user:1000 name "张三" age 30 这样的哈希结构时，user:1000 这个Key本身会被共享，从而减少内存重复占用，不过要注意，这个优化是Redis内部行为，我们不能直接控制,但使用规范的前缀命名无疑增加了这种优化的可能性。

第三招：把相关的字段“打包”进Hash。

这是节省空间的大杀器，考虑一个用户对象，我们有用户的ID、姓名、年龄、城市等信息,一种做法是为每个字段单独设一个Key：

set user:1000:name "张三"
set user:1000:age 30
set user:1000:city "北京"

这种方式下，你存了3个Key，每个Key除了字段值，还有它自己的元数据开销，而且Key的名字user:1000:name本身就很长。

更聪明的做法是使用Hash数据结构：

hset user:1000 name "张三" age 30 city "北京"

你只有一个Key user:1000，所有的字段和值都作为这个Hash的成员存储在一起,这样做的好处是：

1. Key的数量急剧减少,每个Key的元数据开销也相应减少。
2. 字段名（name, age, city）在Hash内部存储时，Redis有优化机制，使得这些字段名的存储效率比作为独立Key的一部分要高得多，特别是当你的字段名本身不长，但需要用在大量对象上时（比如每个用户都有name字段）,这种优化效果非常明显。

这把所有数据都放在了一起，需要考虑数据过期和更新的粒度问题，但如果业务上允许整存整取，或者批量更新,Hash结构是首选。

第四招：把“小数据”整合进Key本身。

这个技巧有点“投机取巧”，但在特定场景下非常有效，比如说，你需要存储用户的性别，性别通常就一个字符（如‘M’代表男，‘F’代表女），你当然可以单独用一个String类型的Key来存,或者像上面说的放在Hash里。

但还有一种思路是，直接把性别信息编码进Key的名字里。 instead of user:1000 和一个单独的性别字段，你可以创建像 user:1000:M 这样的Key，这样，当你看到这个Key的时候，你就知道用户ID是1000，性别是男,这完全省去了存储性别字段的空间。

这种方法的适用场景很有限：必须是那些值域很小、且不经常变化的属性（比如类型、状态、性别等），而且它的缺点是破坏了数据的结构化，查询起来可能会变得麻烦（比如你想查找所有男性用户，可以用 KEYS user:*:M，但这种方式在生产环境不推荐，容易阻塞服务），这是一把双刃剑,用之前要仔细评估业务场景。

第五招：定期清理“僵尸Key”和优化存储。

节省空间不仅是“节流”，更要“开源”，很多时候，数据库里会堆积大量已经过期但未被及时清除的Key，或者设置永不过期但实际上早已不再使用的“僵尸Key”，定期使用Redis的 SCAN 命令（千万不要在生产环境用会阻塞的 KEYS *）来扫描和清理这些无用Key,能直接释放出可观的内存。

如果Redis实例中的数据经过大量删除修改，可能会产生内存碎片，可以尝试在业务低峰期使用 MEMORY PURGE（取决于版本）或通过重启后重新加载数据的方式来整理碎片,让内存使用更紧凑。

优化Redis的Key使用，是一个从细节入手、积少成多的过程，养成给Key起短名、善用Hash结构、定期清理的好习惯，可能在不增加一分钱成本的情况下，就让你的Redis跑得更轻快,何乐而不为呢？