Redis查询条件加得更细，性能提升其实没那么难理解

开始）

我们平时用Redis,很多时候就是简单地set一个值，或者get一个值，但有时候，业务变复杂了，我们想找东西的条件也变多了，你有一个存储了百万用户信息的Redis，以前可能只是通过用户ID来找人，现在产品经理说，我们想根据城市、年龄范围、最后登录时间一起来筛选用户，这时候，你可能会想，这不像在数据库里写SQL那么简单啊，Redis怎么搞？

Redis查询条件加得更细,性能提升的道理并不神秘，说白了，核心思想就是“用空间换时间”和“把计算提前做好”。

第一个关键点：别让Redis去“全表扫描”。

Redis是单线程的,它最怕的就是一条命令过来，让它把所有数据都翻一遍，就像你在一个巨大的、没有按字母顺序排列的通讯录里找一个电话号码，只能一页一页地翻，那得找到什么时候？在Redis里实现多条件查询，首要原则就是避免使用KEYS或者SCAN这种可能遍历所有键的命令作为常规查询手段（它们通常只用于调试或管理），我们必须想办法直接“定位”到我们想要的数据。

那怎么直接定位呢？这就引出了第二个关键点。

第二个关键点：用好“索引”，就像图书馆的目录卡。

在传统数据库里,索引我们听得多了，在Redis里，虽然没有自动创建的索引概念，但我们可以手动创建类似索引的结构，最常用的工具就是有序集合（Sorted Set） 和集合（Set）。

举个例子,还拿用户信息来说，假设每个用户的信息用一个Hash来存储，键名是user:1001，user:1002这样。

• 单条件查询： 如果我们要按城市找用户，比如找所有“北京”的用户，我们可以创建一个集合（Set），键名叫city:北京，然后把所有北京用户的ID（比如1001, 1005, 1008）都塞进这个集合里，这样，当需要查询北京用户时，一条SMEMBERS city:北京命令，瞬间就能拿到所有符合条件的用户ID，然后再用这些ID去获取具体的用户Hash信息，这个过程非常快。
• 多条件组合查询： 现在条件升级了，要找“北京”的、年龄在20到30岁之间”的用户，怎么办呢？我们可以为每个条件都建立这样的“索引集合”。
  • 我们已经有了city:北京这个集合。
  • 我们再为年龄创建索引,但年龄是个范围，用集合就不太方便了，这时有序集合（Sorted Set）就派上用场了，我们可以创建一个有序集合age:index，把用户的ID作为成员（member），用户的年龄作为分数（score），这样，要查询年龄在20到30岁之间的用户，只需要一条ZRANGEBYSCORE age:index 20 30命令。

我们手里有两个结果集：一个是“北京的用户ID集合”（来自Set），一个是“年龄20-30的用户ID集合”（来自ZSet），要找出同时满足两个条件的人，就是求这两个集合的交集，Redis非常贴心地提供了SINTER命令，可以求多个Set的交集，我们一个是Set，一个是ZSet，类型不同怎么交集？这里有个小技巧，Redis的ZINTERSTORE命令可以计算多个ZSet的交集，并把结果存到一个新的ZSet中，我们可以把city:北京这个Set，暂时看作一个所有成员分数都为1的ZSet，然后和age:index这个ZSet求交集。

这个过程,就相当于我们手动模拟了数据库的“联合索引”，我们通过预先建立好这些索引数据结构，把根据条件筛选用户的这个“计算”工作，分摊到了数据插入或更新的时候（比如用户注册时，我们就把他/她的ID加到对应的城市集合和年龄有序集合里），当真正查询的时候，Redis要做的只是进行非常高效的集合运算（交集、并集等），而不是去遍历每一个用户。

第三个关键点：空间换时间，权衡是关键。

你可能会发现,上面这种方法需要存储很多额外的数据，除了每个用户本身的Hash数据，我们还多了很多Set和ZSet来存索引，这就是典型的“用空间换时间”，我们消耗了更多的内存，换来的是查询时毫秒级的响应速度。

这对于需要高性能读写的场景是非常值得的,但这也要求我们在设计时要权衡：

1. 哪些查询条件是高频的？只为这些条件建索引，避免内存无限膨胀。
2. 数据更新（比如用户修改了城市）时，需要同时更新对应的索引集合，这会增加写操作的复杂度，但为了保证数据一致性，这是必须付出的代价。

Redis查询条件加得更细,性能还能提升，秘诀不在于Redis本身有什么黑魔法，而在于我们如何使用它提供的数据结构（Set， ZSet等），聪明地、手动地构建出“索引”，核心思路就是把查询时耗时的“筛选”过程，转变为插入/更新时的“预分类”和查询时的“快速集合运算”，只要你理解了“避免遍历”和“空间换时间”这两个基本原则，就能设计出满足复杂查询需求的高性能Redis方案，这就像整理仓库，平时多花点时间把货物分门别类放好（建索引），等真要找什么东西的时候（查询），就能直奔主题，而不需要翻遍整个仓库。 结束）