Redis查询技巧分享，聊聊那些让效率飞起来的小妙招

今天咱们不聊那些深奥的原理，就聊聊实际用Redis时，有哪些立竿见影的小技巧能让你的查询速度“嗖”的一下提上来，这些东西就像是工具箱里的小工具，平时可能不起眼，但用对了地方,效果惊人。

第一招：别让键（Key）太“任性”，给它穿上规矩的外衣。

很多人刚开始用Redis，给键取名很随意，user123，order456，短期看没问题，但项目一大，键一多，管理和查找就成了噩梦，这里有个小妙招：使用统一的命名规范，比如用冒号 来构造层次结构，像这样：users:123:profile，orders:456:items，这看起来只是多了几个冒号，但好处巨大，非常清晰，一眼就知道这个键存的是用户123的个人资料，当你需要批量删除或查找某一类键时，可以使用 KEYS users:* 或者更高效的 SCAN 命令（后面会提到）来模式匹配，事半功倍，这就好比把你的文件按文件夹分门别类，找起来当然快多了。（这个命名规范在Redis官方文档和一些最佳实践文章中被广泛推荐）

第二招： Pipeline（管道）—— 把多次往返变成一次“快递”。

想象一下，你要从仓库取十件货，如果取一件跑一趟，来来回回十次，大部分时间都花在路上了，Redis的查询也是这个道理，每个命令从客户端发到服务器再返回，这个网络传输的时间（称为网络延迟）其实很可观，如果你要执行一连串的命令，比如要获取一个用户的好友列表里每个人的详细信息，常规做法是发一个 LRANGE 取好友ID，然后对每个ID发一个 HGETALL，这就是典型的“N+1查询”,效率极低。

这时候，Pipeline（管道）就派上用场了，它的思想很简单：把多个命令打包成一个“包裹”，一次性发送给Redis服务器，服务器处理完所有命令后，再把结果打包成一个“包裹”一次性返回给你，这样，无论你要执行100个还是1000个命令，网络延迟都只发生一次，这个性能提升，尤其是在网络环境不理想或者命令数量很多的时候，是数量级的飞跃，很多Redis客户端都支持Pipeline，用法也很简单，就像是把要执行的命令先放进一个列表里，然后统一提交。（这个技巧在Redis的性能优化指南中是必提项）

第三招： 巧妙选择数据结构，就像用对的工具干对的活。

Redis不只是简单的键值存储，它提供了丰富的数据结构，用对了是神器,用错了就是累赘。

• 场景1：统计网站每天的独立访客。 你可能会想到用集合（Set），把每个访客的ID塞进去，因为集合自动去重，最后用 SCARD 命令看大小就知道总人数，这没问题，但如果访问量巨大，比如一天几百万UV，一个集合会占用很大内存，这时候，可以祭出“黑科技”—— HyperLogLog，它也是用来做基数统计（去重计数）的，特点是极其节省内存，可能只需要12KB内存，就能统计上亿个独立元素，并且误差率不到1%，用 PFADD 添加元素，PFCOUNT 获取统计值，非常适合这种对精确度要求不极致的海量数据统计场景。（HyperLogLog是Redis提供的一种概率数据结构）

• 场景2：需要存储一个对象的多个字段。 比如用户信息有姓名、年龄、城市等，新手可能会用多个独立的键来存，user:123:name, user:123:age，这会导致键数量膨胀，管理不便，更优雅的方式是使用哈希（Hash），一个哈希键 user:123 里面可以包含多个字段（field）和值（value），一次性用 HMSET 设置，用 HGETALL 获取全部，或者用 HMGET 获取部分，这样数据更紧凑,操作也更高效。

第四招： 慎用 KEYS 命令，请用 SCAN 来“扫荡”。

当你需要查找所有符合某个模式的键时（比如查找所有以 users: 开头的键），第一个想到的命令可能是 KEYS users:*。请务必谨慎！ 这个命令在生产环境几乎可以看作是一个“灾难”命令，因为Redis是单线程的，KEYS 命令会一次性遍历数据库中的所有键，如果数据库里有几百万、几千万个键，这个命令会阻塞其他所有命令长达数秒甚至更久,导致服务瞬间不可用。

那该怎么办呢？答案是使用 SCAN 命令。SCAN 命令采用迭代器的方​​式，每次只返回一小部分结果和一个游标（cursor），你根据返回的游标再次调用 SCAN，直到游标为0表示遍历完成，虽然整个过程可能比 KEYS 慢一点，但它是非阻塞的，每次执行都只占用很少的时间片，不会影响Redis的正常服务，这是一个非常重要的生产环境最佳实践。（Redis官方强烈警告不要在生产环境使用 KEYS 命令，并推荐其替代品 SCAN）

第五招： 让热点数据“住”在离计算最近的地方——客户端缓存。

对于一些几乎不变或者变化频率很低的热点数据，比如城市列表、配置信息等，每次查询都去访问Redis，虽然Redis本身很快，但网络开销依然存在，更进一步的做法是使用客户端缓存，就是在应用服务器本地内存里也存一份这些数据，并设置一个短暂的过期时间，查询时先看本地有没有，有且未过期就直接返回,没有再去查Redis并更新本地缓存。

这样做的好处是，对极端热点的数据，请求根本不用走到Redis网络层，直接在应用内部就解决了，速度是最快的，这带来了数据一致性的问题，需要根据业务场景权衡缓存的过期时间，通常适用于允许短暂延迟的数据。（这是一种常见的分布式缓存设计模式，通常称为“两级缓存”）

这些技巧的核心思想就是：规范、批量、精准、非阻塞、就近，希望这些实实在在的小妙招能帮你把Redis用得更加得心应手,真正让效率飞起来。