Redis查询所有key的命令是什么？

Question

在Redis中，常被问到“查询所有key的命令是什么”？许多开发者误以为`KEYS *`是生产环境下的理想选择。然而，该命令会遍历整个键空间，在数据量大时会导致服务阻塞，严重影响性能。因此，一个典型的技术问题是：**为什么不推荐在生产环境中使用 KEYS * 命令查询所有Key，以及有哪些安全替代方案？** 此问题涉及Redis的单线程模型、阻塞风险及SCAN命令的渐进式遍历机制，是实际运维中的关键知识点。

Answer 1

1. 为什么 KEYS * 不推荐在生产环境中使用？

在 Redis 中，KEYS * 命令用于匹配并返回所有符合指定模式的键。虽然它在开发或调试阶段非常方便，但在生产环境中直接使用 KEYS * 存在严重的性能隐患。

Redis 是单线程架构，所有命令按顺序执行。当执行 KEYS * 时，Redis 必须遍历整个键空间进行模式匹配。如果数据库中存在数百万甚至上千万个 key，该操作可能耗时数秒甚至更久，在此期间，Redis 无法处理其他客户端请求，导致服务“卡死”或超时。

例如，以下命令将阻塞主线程：

127.0.0.1:6379> KEYS *
1) "user:1001"
2) "user:1002"
...
1000000) "session:xyz"

这种阻塞性质与 Redis 的高性能设计初衷相违背，尤其在高并发场景下极易引发雪崩效应。

2. Redis 单线程模型与阻塞风险分析

Redis 使用单线程事件循环（Event Loop）处理所有客户端命令。这意味着每个命令必须完全执行完毕后，下一个命令才能开始执行。这种设计简化了并发控制，提升了缓存访问速度，但也带来了“长耗时命令即服务中断”的问题。

下表对比了不同命令的时间复杂度及其对系统的影响：

命令	时间复杂度	是否阻塞	适用场景
GET/SET	O(1)	否	常规读写
KEYS *	O(N)	是	仅限调试
SCAN	O(1) 每次调用	否	生产环境遍历
FLUSHALL	O(N)	是	慎用

从上表可见，KEYS * 的 O(N) 复杂度使其成为潜在的系统瓶颈。

3. 安全替代方案：SCAN 命令详解

Redis 提供了非阻塞的渐进式遍历命令 —— SCAN，它是解决大规模键空间查询问题的核心工具。SCAN 并不一次性返回所有匹配 key，而是通过游标（cursor）分批获取结果。

基本语法如下：

SCAN cursor [MATCH pattern] [COUNT count]

示例：逐步遍历所有以 user: 开头的 key

127.0.0.1:6379> SCAN 0 MATCH user:* COUNT 100
1) "456"
2) 1) "user:1001"
   2) "user:1002"
...
127.0.0.1:6379> SCAN 456 MATCH user:* COUNT 100
1) "0"
2) 1) "user:1003"

当返回游标为 0 时表示遍历完成。每次调用只处理少量数据，不会显著影响主线程性能。

4. 其他相关迭代器命令与应用场景

除了全局的 SCAN，Redis 还提供了针对特定数据结构的扫描命令，形成了一套完整的非阻塞遍历体系：

• SSCAN：遍历 Set 成员
• HSCAN：遍历 Hash 字段
• ZSCAN：遍历 Sorted Set 元素

这些命令均采用相同的游标机制，确保在遍历大型集合时不会造成服务中断。例如：

HSCAN user:profile:1001 0 MATCH name*

可用于查找用户资料中所有名称相关的字段，而不会因 hash 过大导致延迟。

5. 实际运维中的最佳实践建议

为了保障 Redis 在生产环境中的稳定性，应遵循以下原则：

1. 禁止在生产环境使用 KEYS *、FLUSHDB、FLUSHALL 等危险命令，可通过重命名或禁用方式防范。
2. 使用 SCAN 替代 KEYS 进行键空间检查，配合脚本实现完整遍历。
3. 设置合理的 COUNT 参数（通常 100~500），平衡吞吐量与延迟。
4. 避免在高峰期执行大规模扫描任务，可安排在低峰期进行监控或清理。
5. 结合 Lua 脚本实现原子性操作，但需注意脚本不可过长。
6. 启用慢查询日志（slowlog）监控异常命令执行。
7. 使用 Redis 监控工具（如 RedisInsight、Prometheus + redis_exporter）持续观察延迟指标。
8. 对 key 设计规范命名空间（如 service:type:id），便于后续维护和排查。
9. 考虑使用 Redis Module（如 RedisSearch）实现高效索引查询。
10. 对于频繁查询的需求，应在应用层维护元数据索引，避免反复扫描。

6. SCAN 执行流程图解

以下是 SCAN 命令的执行逻辑流程图：

graph TD
    A[客户端发起 SCAN 0 MATCH * COUNT 100] --> B{Redis 返回一批 key 和新游标}
    B --> C[客户端判断游标是否为0]
    C -- 否 --> D[发起 SCAN 新游标 MATCH * COUNT 100]
    D --> B
    C -- 是 --> E[遍历结束]

该流程体现了 SCAN 的“懒加载”特性，将原本一次性的高负载操作拆分为多个轻量级请求。