Redis里索引和唯一索引怎么帮查询快点，感觉挺重要的事情吧

你感觉Redis里索引和唯一索引能帮查询变快是件重要的事情,这个感觉非常对，虽然Redis本身不像传统数据库（比如MySQL）那样有直接的“创建索引”这种命令，但它通过自身灵活的数据结构和用法，巧妙地实现了索引的功能，而且效果非常好，下面我们就来详细聊聊这是怎么一回事。

核心思想：用空间换时间

首先要明白一个基本道理：想让查询变快，很多时候需要用“空间”来换“时间”，简单说，就是你多占一点内存，预先存一些额外的东西，这样当你要找数据的时候，就不用像翻大口袋一样把所有数据都摸一遍，而是能直接去拿，这个“额外存的东西”，就是索引，在Redis里，这个“东西”通常就是各种各样的键（Key）。

Redis是怎么实现“索引”的？

想象一下,你有一堆用户信息，每个用户是一个哈希表（Hash），用user:用户ID作为键名存储，比如user:1001、user:1002，现在你想根据用户ID查信息，这很快，因为你知道键名，直接用HGETALL user:1001就行了，这本身就已经很快了，因为Redis是内存数据库，根据键名找值是其看家本领。

但问题来了,如果你想根据“城市”来查找所有在北京的用户，怎么办？Redis可没有直接的命令说“把所有城市字段是北京的哈希表给我找出来”，这时候，就需要我们自己建立索引。

普通索引（或者说“二级索引”）怎么建？

最常见的办法是利用集合（Set） 或有序集合（Sorted Set）。

• 集合（Set）索引： 你可以创建一个键，比如index:city:北京，它的值是一个集合（Set），这个集合里存放的不是用户的具体信息，而是所有在北京的用户的ID。

  

  • 当添加用户1001（城市是北京）时，你除了执行HSET user:1001 city 北京 ...，还要执行一个SADD index:city:北京 1001。
  • 同样,添加用户1005（城市也是北京）时，也执行SADD index:city:北京 1005。

  当你需要查询所有在北京的用户时,你不再需要扫描所有user:*键，而是直接执行SMEMBERS index:city:北京，这个命令会立刻返回一个包含1001和1005的集合，然后你再根据这些ID，用HGETALL user:1001和HGETALL user:1002去获取详细信息，虽然看起来是两步，但每一步都极快，避免了全表扫描。

• 有序集合（Sorted Set）索引： 如果你还想根据城市索引的基础上再进行排序，比如按用户的积分排序，有序集合就派上用场了。 你可以创建index:city:北京:score，把用户ID作为成员（member），把用户积分作为分值（score）存进去，这样，查询“在北京的用户，按积分从高到低排”就变得非常简单高效，直接用ZREVRANGE index:city:北京:score 0 -1即可。

唯一索引怎么实现？

唯一索引的目的就是保证某个字段的值是唯一的,比如用户的邮箱、用户名，在Redis里，实现这个主要靠字符串（String） 键的“键唯一”特性。

• 实现方法： 假设你要保证用户的邮箱是唯一的，你可以这样做： 创建一个键，格式比如是unique:email:用户邮箱地址，它的值可以简单地设为对应用户的ID。 用户1001的邮箱是zhangsan@example.com。

  

  • 在注册新用户时,你先执行一个检查：SET unique:email:zhangsan@example.com 1001 NX，这个NX参数是关键，意思是“如果这个键不存在才设置它”，如果设置成功，说明这个邮箱还没被占用。
  • 如果设置失败（返回nil），说明unique:email:zhangsan@example.com这个键已经存在，意味着邮箱已被注册，你就应该拒绝这次注册。
  • 注册成功后,你依然要像往常一样把用户信息存到user:1001这个哈希里。

  这样一来,通过一个额外的、以邮箱为部分的字符串键，你就轻松实现了邮箱的唯一性约束，检查速度极快，就是一次SET ... NX操作。

为什么这种方式快？

如前面所说,Redis所有数据都在内存中，无论是根据index:city:北京这个键去集合里取用户ID，还是检查unique:email:xxx这个键是否存在，都是直接的内存访问操作，时间复杂度通常是O(1)或O(log N)，这比去磁盘上搜索或者遍历所有数据要快几个数量级。

需要注意的地方

这种强大的能力也需要你付出一些代价和管理精力：

1. 数据一致性：因为你手动维护了索引，所以你必须确保在更新或删除主数据（如user:1001）时，同时更新或清理所有相关的索引，如果用户1001从北京搬到了上海，你需要：
   • 把他从index:city:北京集合中移除（SREM index:city:北京 1001）。
   • 把他加入到index:city:上海集合中（SADD index:city:上海 1001）。
   • 更新user:1001中的城市字段。 这需要在一个事务（例如用MULTI/EXEC）中完成，以保证原子性，避免出现数据不一致。
2. 内存消耗：索引是要占用额外内存的，如果你的数据量极其庞大，索引可能会占用很多空间，这就需要你在查询速度和内存成本之间做权衡。
3. 设计复杂度：你需要事先想好哪些字段需要被查询，从而建立合适的索引，这增加了设计的复杂性，但这是为了换取极致性能必须做的。

总结一下

回到你的问题,Redis确实通过巧妙运用其基本数据结构（Set, Sorted Set, String等）来实现索引和唯一索引的功能，它不像SQL数据库那样声明式地创建索引，而是需要开发者显式地、手动地通过存储额外的键值对来构建，这种方法虽然增加了开发的复杂度，但赋予了极大的灵活性，并能充分发挥Redis内存高速访问的优势，最终让特定模式的查询变得非常非常快，你觉得这件事重要，是完全正确的，因为是否合理地使用和维护索引，是决定一个Redis应用性能好坏的关键因素之一。