Redis 是一种高性能的内存数据库，常用于缓存、消息队列、会话存储等场景，在 Redis 中，KEYS 命令是一个用于查找所有符合指定模式键的命令，其语法为 KEYS pattern，pattern 是匹配键名的模式，支持通配符如 （匹配任意数量的字符）、（匹配单个字符）和 []（匹配指定范围内的字符）。KEYS user:* 会返回所有以 user: 为前缀的键，尽管 KEYS 命令功能强大，但在生产环境中需要谨慎使用，因为它会遍历整个键空间，导致 Redis 实例阻塞，影响性能，本文将详细介绍 KEYS 命令的使用方法、注意事项、替代方案以及实际应用场景。
KEYS 命令的基本用法
KEYS 命令的语法简单，但模式匹配的灵活性使其能够满足多种查询需求,以下是常见的模式匹配示例：
| 模式 | 说明 | 示例键 | 匹配结果 |
|---|---|---|---|
KEYS * |
匹配所有键 | user:1, product:2 |
user:1, product:2 |
KEYS user:* |
匹配以 user: 为前缀的键 |
user:1, user:2 |
user:1, user:2 |
KEYS ?ser:* |
匹配第二个字符为 ser 的键 |
user:1, xser:2 |
user:1, xser:2 |
KEYS u[za]:* |
匹配第一个字符为 u 且第二个字符为 z 或 a 的键 |
uz:1, ua:2 |
uz:1, ua:2 |
需要注意的是，KEYS 命令是区分大小写的，KEYS User:* 和 KEYS user:* 会匹配不同的键。KEYS 命令返回的是所有匹配的键列表，如果键的数量很大，可能会占用大量内存，甚至导致 Redis 实例崩溃。
KEYS 命令的性能影响
KEYS 命令的性能问题主要源于其实现方式，在 Redis 中，键空间是一个哈希表，而 KEYS 命令会遍历哈希表中的所有键，逐个检查是否匹配指定的模式，当 Redis 中存储的键数量达到百万级别时，KEYS 命令的执行时间可能会从几毫秒延长到几秒甚至更长，期间 Redis 无法处理其他客户端的请求，即进入“阻塞状态”，这种阻塞对高并发场景是致命的，因此官方文档明确建议在生产环境中避免使用 KEYS 命令。
假设一个 Redis 实例中有 100 万个键，执行 KEYS * 命令可能需要数秒时间，而在此期间，所有读写请求都会被阻塞，导致应用程序响应超时。KEYS 命令仅适用于开发环境或键数量极少的场景。
KEYS 命令的替代方案
为了避免 KEYS 命令的性能问题，Redis 提供了以下替代方案：
SCAN 命令
SCAN 命令是 Redis 2.8 引入的迭代器，用于逐步遍历键空间，避免阻塞，其语法为 SCAN cursor [MATCH pattern] [COUNT count]，cursor 是游标，初始值为 0，每次迭代返回一个新的游标，当游标为 0 时表示遍历结束。MATCH 参数用于指定模式，COUNT 参数建议每次返回的键数量（默认为 10）。
使用 SCAN 遍历所有键的代码片段（伪代码）：
cursor = 0
while True:
cursor, keys = redis.scan(cursor, match="user:*", count=100)
for key in keys:
print(key)
if cursor == 0:
break
SCAN 命令的优势在于非阻塞，但需要注意的是，它可能会返回重复的键（在迭代过程中有键被删除或添加），且无法保证返回所有键（因为迭代过程中可能有数据变更）。
使用命名空间和 INFO 命令
如果业务逻辑中已经通过命名空间（如 user:, product:）对键进行了分类，可以通过 INFO keyspace 命令获取每个数据库的键数量，但无法直接获取键名，可以结合 SCAN 命令和命名空间模式进行查询。
维护外部索引
对于复杂的键查询需求，可以维护一个外部索引（如 Redis 的 Hash 或关系型数据库），记录键与业务逻辑的映射关系，使用 Hash 存储键名和标签，通过 HGETALL 或 HSCAN 查询。
KEYS 命令的实际应用场景
尽管 KEYS 命令存在性能问题,但在某些场景下仍然可以使用：
- 开发环境调试：在开发或测试环境中，键数量较少，使用
KEYS命令可以快速查看所有键或特定模式的键,方便调试。 - 临时维护操作：在低峰期进行维护时，如果需要一次性获取所有键进行批量操作（如删除过期键），可以临时使用
KEYS命令,但需确保键数量可控。 - 小规模 Redis 实例：对于键数量极少（如几千个）的 Redis 实例，
KEYS命令的性能影响可以忽略。
KEYS 命令是 Redis 中用于查找键的强大工具，但其阻塞特性使其不适合生产环境的高并发场景，在实际应用中，应优先使用 SCAN 命令或其他替代方案，避免因 KEYS 命令导致 Redis 性能问题，通过合理的键命名和索引设计，可以减少对键查询的依赖,提升系统的整体性能。
相关问答 FAQs
问题 1：KEYS 命令和 SCAN 命令有什么区别？
解答：KEYS 命令会阻塞 Redis 服务器，一次性返回所有匹配的键，适用于键数量较少的场景；而 SCAN 命令是迭代器，非阻塞地逐步返回匹配的键，适用于生产环境的大规模键空间遍历。SCAN 命令可能返回重复键或无法保证遍历所有键，而 KEYS 命令返回精确结果。
问题 2：如何在生产安全地查询特定模式的键？
解答：在生产环境中，应避免使用 KEYS 命令，改用 SCAN 命令，使用 SCAN 0 MATCH user:* COUNT 100 逐步遍历所有以 user: 为前缀的键，并设置合理的 COUNT 值（如 100-1000）以平衡性能和响应时间，可以在低峰期执行查询，减少对业务的影响，如果键数量极大，建议维护外部索引或使用 Redis 的集群功能分散查询压力。
