版本说明

以下命令在 Redis 5.0/6.0/7.0 均通用，SCAN 系列命令自 2.8 起就已存在。

1. 连接与基础排查

登录一个 Redis 实例，常见参数组合：

redis-cli -c -a <REDIS_PWD> -p 6379 -h <redis-host> --raw

• -c：cluster 模式下自动跟随 MOVED 重定向，单机模式不需要
• -a：密码认证（命令行传密码会有安全告警，生产环境建议改用 --pass 从文件读取或用 REDISCLI_AUTH 环境变量）
• --raw：以原始格式输出（不加会把中文等内容转成转义字符，调试时体验很差）

检查慢查询相关配置（排查性能问题的第一步）：

config GET slowlog-log-slower-than   # 慢查询阈值，单位微秒，-1表示关闭，0表示记录所有
config get slowlog-max-len           # 慢查询日志最多保留多少条

2. Redis 支持的五种数据类型，怎么选

Redis 支持 string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合）五种基础数据类型，选型的关键在于你要对这份数据做什么操作：

• 简单的键值对、计数器 → string
• 一个对象的多个字段（如用户信息） → hash（比拆成多个 string key 更省内存，也更符合语义）
• 有序的、可能重复的元素序列（如消息队列、最近访问记录） → list
• 去重的元素集合、判断成员是否存在 → set
• 需要按分数排序的集合（如排行榜） → zset

3. 各类型的查询命令

通用：判断 key 是否存在 / 查看类型

exists key      # 返回1存在，0不存在
type key        # 返回 string / hash / list / set / zset / none

string

GET key

hash（键值对集合）

HGETALL key

坑：HGETALL 会一次性返回全部字段，对于有几十万个 field 的大 Hash（大 key），这会瞬间阻塞 Redis 主线程并占用大量网络带宽——大 Hash 场景应该用 HSCAN 分批游标遍历，而不是一次性 HGETALL。

list（列表）

LRANGE key 0 10   # 查看前11个元素（索引0到10，闭区间）
LLEN key          # 查看列表长度

set（无序集合）

SMEMBERS key

同样，对于成员数量巨大的 set，SMEMBERS 一次性返回全部成员有阻塞风险，大 set 建议用 SSCAN 分批取。

zset（有序集合）

ZRANGE key 0 10 WITHSCORES   # 按分数升序取前11个，附带分数

4. 模糊匹配 key：为什么不能用 KEYS

需要按前缀/模式查找 key 时，很多人第一反应是：

KEYS my_test_key*

坑（重要）：KEYS 命令会遍历整个 keyspace，是阻塞式的 O(N) 操作——在 key 数量较多的生产实例上执行 KEYS，会导致 Redis 在遍历完成前无法处理任何其他请求，是公认的生产环境高危命令。正确做法是用 SCAN 做渐进式遍历：

scan 0 match my_test_key* count 999

SCAN 每次只返回一小批结果和一个游标（cursor），下次调用带上这个游标继续，不会一次性锁住整个实例；count 只是"建议每次扫描多少个桶"，不是精确返回条数。用返回的游标反复调用 SCAN 直到游标变回 0，即遍历完成。

验证：脚本化遍历时注意判断终止条件是游标回到 0，而不是某次返回结果为空——SCAN 单次返回空结果不代表遍历已结束。

5. 可复用要点

1. 选数据类型看语义和操作模式：对象用 hash，去重集合用 set，排行榜用 zset。
2. HGETALL/SMEMBERS 对大 key 有阻塞风险，大集合场景改用 HSCAN/SSCAN 游标分批遍历。
3. 永远不要在生产环境执行 KEYS，模糊匹配一律用 SCAN，这是新手最容易踩的坑，也是最容易造成生产事故的命令之一。