Redis里怎么快速找到你要的那个Key，查询数据时的小技巧分享

很多人刚开始用Redis的时候，会有一个习惯性的想法，就是像在数据库里用SQL查询一样，希望能用一些模糊的条件去搜索Key，找出所有以‘user_’开头的Key”或者“找出所有包含‘2024’的Key”，Redis确实提供了这样的命令，最常用的就是KEYS命令。

你可以在Redis的命令行里直接输入KEYS *，它会列出所有的Key，如果你想找特定的模式，比如所有以“cart”开头的Key，可以输入KEYS cart*，这个命令看起来非常直接和方便，但这里就要分享第一个也是最重要的一个小技巧了：在生产环境里，千万不要轻易使用KEYS命令。

这是为什么呢？根据Redis官方文档（来源：Redis官方文档对KEYS命令的说明）的解释，Redis是单线程的，这意味着它在任何一个时刻只能做一件事，当你执行KEYS *这样的命令时，如果数据库里有几百万甚至上千万个Key，Redis需要遍历整个Key空间来匹配你的模式，这个过程可能会阻塞服务器好几秒钟，在这几秒钟里，Redis无法处理其他任何请求，比如你的应用正在发起的读取或写入操作，这就会导致服务卡顿甚至超时,对线上业务来说是灾难性的。

既然KEYS命令这么危险，我们该怎么安全地快速找到想要的Key呢？这就引出了第二个小技巧：使用SCAN命令来替代KEYS。

SCAN命令的设计非常巧妙，它也是用来迭代数据库中的Key的，但它的工作方式不是一次性把所有结果都给你，而是分批次的、游标式的，你第一次执行SCAN 0（0代表从头开始），它会返回一小部分Key和一个新的游标数字，你拿着这个新的游标数字，再执行SCAN [新游标]，它就会给你下一批Key，这样一点点地迭代，直到返回的游标是0,就表示全部遍历完了。

这种方式最大的好处是非阻塞，因为每次只扫描一小部分，所以每次操作都很快，不会长时间占用Redis的主线程，不会影响其他操作的正常进行，虽然它可能需要多次请求才能拿到全部结果，但保证了服务的稳定性。SCAN命令也支持模式匹配，比如SCAN 0 MATCH user*就能分批找出所有以“user”开头的Key。

除了查询命令本身的选择，更重要的技巧其实是在使用Redis之前的设计阶段，这就是第三个技巧：从源头设计好Key的命名规范。

如果你能从一开始就把Key的名字规划得清晰、有规律，那么后期查找和管理会容易得多，你要存储用户信息、订单信息和购物车信息,可以这样设计Key：

• 用户信息：user:123（123是用户ID）
• 订单信息：order:20240520:789（20240520是日期,789是订单ID）
• 购物车信息：cart:123（123对应用户ID）

这种用冒号分隔的命名方式是一种非常通用的约定，它本身就像一种分类路径，当你使用SCAN命令时，就可以用SCAN 0 MATCH user:*来精确查找所有用户Key,避免了模糊匹配可能带来的不必要的性能开销。

第四个技巧是关于特定数据类型的：利用合适的数据结构来辅助查询，你不仅仅是想列出Key，而是想根据Value里的某些内容来反向找Key，这对于普通的Key-Value存储是很难的，但如果你使用了Redis的集合（Set）或有序集合（Sorted Set）,就能实现。

举个例子，假设你想给用户打标签，比如用户A有“VIP”和“北京”两个标签，用户B有“新用户”和“北京”的标签，你可以为每个标签创建一个集合（Set）：

• Key tag:VIP，Value是 {用户A的ID}
• Key tag:新用户，Value是 {用户B的ID}
• Key tag:北京，Value是 {用户A的ID, 用户B的ID}

如果你想快速找出所有“北京”的用户，直接取tag:北京这个Key对应的集合就行了，速度极快，根本不需要扫描，这是一种“空间换时间”的思想，通过维护额外的索引结构,来换取极高的查询效率。

第五个小技巧是给你的开发工作提供便利的：利用图形化管理工具，比如RedisInsight、Another Redis Desktop Manager等这些工具，它们通常都提供了可视化的Key浏览器，会自动在后台使用安全的SCAN命令来为你展示Key的列表，并且可以按模式过滤、查看Value、甚至分析内存占用，对于开发和测试阶段来说，用这些工具来浏览和查找Key,比在命令行里敲命令要直观和安全得多。

在Redis里快速找Key的核心思路是：避免在生产环境使用阻塞命令KEYS，用游标迭代命令SCAN代替；更重要的是，通过良好的Key命名规范和合理利用集合等数据结构建立索引，从设计上就让查找变得简单直接；借助图形化工具提升开发和排查问题的效率。