在 Redis 日常开发中，我们经常需要遍历数据库中的键或集合中的元素。传统的
keys命令虽然简单直接，但在数据量较大时会严重阻塞 Redis 服务，甚至引发生产事故。而scan命令作为 Redis 2.8 版本引入的渐进式遍历方案，完美解决了这一痛点。
一、为什么需要 scan？先看 keys 命令的 "坑"
在了解scan之前，我们首先要明确：为什么不能在生产环境中随意使用keys命令？
keys命令的工作方式是全量遍历------ 它会一次性遍历 Redis 中的所有键，并将符合模式的结果全部返回。这种方式存在两个致命问题：
-
阻塞服务 ：Redis 是单线程模型，
keys命令执行期间会占用主线程，导致其他请求（如读写操作）无法响应，数据量越大，阻塞时间越长（毫秒级到秒级不等）； -
内存暴涨 ：若符合条件的键数量极多（如 100 万 +），
keys会一次性将所有结果加载到内存，可能引发 Redis 内存溢出或 OS 级别的 Swap，严重时导致服务崩溃。
而scan命令的设计理念是 **"渐进式遍历"**：将全量遍历拆分为多次小规模遍历，每次只返回少量结果（默认 10 个），既不会阻塞主线程，也不会占用过多内存。这使得它成为生产环境中遍历键的首选方案。
二、scan 命令的基础用法：从语法到示例
2.1 核心语法
scan命令的基本格式如下：
SCAN cursor \[MATCH pattern] \[COUNT count] \[TYPE type]各参数的含义如下：
-
cursor ：游标，是
scan的核心标识，用于记录遍历的 "位置"。首次遍历需传入0，后续遍历需传入上一次返回的游标值，直到游标返回0表示遍历结束； -
MATCH pattern ：可选参数，用于过滤符合指定模式的键，支持通配符
*（匹配任意字符）、?（匹配单个字符）、[]（匹配指定范围内的字符）； -
COUNT count ：可选参数，用于指定每次遍历的 "预期返回数量"，默认值为
10。注意：这只是 "预期值"，并非实际返回数量，Redis 会根据内部数据结构调整，可能多也可能少； -
TYPE type ：可选参数，用于过滤指定数据类型的键，支持
string、hash、list、set、zset等，Redis 6.0 + 版本支持。
2.2 基础示例：遍历所有键
假设 Redis 中存在以下键：user:100、user:101、order:200、product:300，我们通过scan遍历所有键：
-
首次遍历 ：传入游标
0，不指定MATCH和COUNT（默认返回 10 个）：127.0.0.1:6379> SCAN 0
1) "14" # 下一次遍历的游标
2) 1) "user:100"
2) "order:200"
3) "product:300"
结果中，第一个元素"14"是下一次遍历的游标，第二个元素是本次返回的键列表（共 3 个，少于默认的 10 个，符合 "预期值" 特性）。
-
第二次遍历 ：传入上一次返回的游标
14：127.0.0.1:6379> SCAN 14
1) "0" # 游标返回0，遍历结束
2) 1) "user:101"
此时游标返回0，表示所有键已遍历完成，本次返回剩余的user:101。
2.3 过滤场景：MATCH 与 TYPE 的使用
场景 1：匹配 "user:" 前缀的键
通过MATCH user:*过滤前缀为user:的键：
127.0.0.1:6379> SCAN 0 MATCH user:\*
1\) "0"
2\) 1) "user:100"
  2\) "user:101"由于符合条件的键较少，一次遍历就完成，游标直接返回0。
场景 2：只遍历 string 类型的键
假设user:100是string类型，order:200是hash类型，通过TYPE string过滤：
127.0.0.1:6379> SCAN 0 TYPE string
1\) "8"
2\) 1) "user:100"三、scan 的核心原理：为什么能 "渐进式" 遍历？
要正确使用scan，必须理解其底层原理 ------基于 Redis 的哈希表结构和游标跳转。
3.1 Redis 的键空间存储：哈希表
Redis 的键空间（keyspace）是通过哈希表 实现的，哈希表中的每个 "桶"（bucket）存储若干个键（通过哈希冲突链解决冲突）。scan的遍历本质是遍历哈希表的桶，而非直接遍历键。
3.2 游标与 "高位进位"
scan的游标并非简单的 "桶索引"，而是基于 "高位进位" 的算法设计：
-
Redis 会为哈希表分配一个固定的 "位数"（如 16 位，对应 65536 个桶），游标是一个无符号整数，长度与哈希表位数一致；
-
每次遍历后，游标会按照 "高位进位" 的规则生成下一个游标（例如，16 位游标
0000000000000000（0）的下一个游标可能是0000000000001000（8），再下一个是0000000000010000（16）等）； -
当游标再次回到
0时，表示所有桶已遍历完成，即整个键空间遍历结束。
3.3 COUNT 参数的 "预期" 特性
为什么COUNT是 "预期值" 而非 "固定值"？原因有两点：
-
哈希冲突 ：一个桶中可能存储多个键，遍历该桶时会返回所有键，导致实际数量超过
COUNT； -
空桶跳过 ：若某个桶中没有键，Redis 会直接跳过，导致实际数量少于
COUNT。
例如，设置COUNT 2，但实际返回 3 个键：
127.0.0.1:6379> SCAN 0 COUNT 2
1\) "12"
2\) 1) "user:100"
  2\) "order:200"
  3\) "product:300" # 因哈希冲突，桶中键数量超过COUNT四、scan 家族命令：不止遍历键
scan是一个 "家族"，除了遍历整个键空间的scan命令，还有针对特定数据类型的渐进式遍历命令，用法与scan一致，仅作用对象不同：
| 命令 | 作用对象 | 用途 |
|---|---|---|
HSCAN |
Hash 类型的字段 | 遍历 Hash 中的 field-value 对 |
SSCAN |
Set 类型的元素 | 遍历 Set 中的所有元素 |
ZSCAN |
Sorted Set 类型的元素 | 遍历 ZSet 中的 member-score 对 |
示例：HSCAN 遍历 Hash 字段
假设user:100是 Hash 类型，存储用户信息：
127.0.0.1:6379> HSET user:100 name "zhangsan" age 25 city "beijing"
(integer) 3通过HSCAN遍历其字段：
\# 首次遍历：游标0，COUNT 2
127.0.0.1:6379> HSCAN user:100 0 COUNT 2
1\) "2" # 下一次游标
2\) 1) "name"
  2\) "zhangsan"
  3\) "age"
  4\) "25"
\# 第二次遍历：游标2
127.0.0.1:6379> HSCAN user:100 2
1\) "0" # 遍历结束
2\) 1) "city"
  2\) "beijing"五、使用 scan 的注意事项与常见误区
5.1 避免 "重复" 与 "遗漏"
scan的设计目标是 "不重复、不遗漏"，但在以下场景可能出现问题：
-
数据动态变化：遍历过程中，若键被添加、删除或修改，可能导致某个键被重复遍历或遗漏。这是渐进式遍历的固有特性，无法完全避免，需在业务层做兼容（如通过唯一 ID 去重）；
-
游标失效：若两次遍历间隔过长（如超过 Redis 的超时时间），游标可能失效，导致遍历中断。建议缩短遍历间隔，确保游标连续性。
5.2 合理设置 COUNT 参数
-
小数据量 ：默认
COUNT 10即可，无需调整； -
大数据量 ：若需加快遍历速度，可适当增大
COUNT（如COUNT 1000），但需注意：COUNT越大，单次遍历占用的主线程时间越长，需在 "速度" 和 "阻塞风险" 间平衡，建议不超过10000。
5.3 避免在遍历中使用复杂过滤
MATCH和TYPE过滤是在 "遍历后" 执行的 ------Redis 会先遍历出一批键，再过滤掉不符合条件的键。若符合条件的键比例极低（如MATCH user:100000*，但实际只有 1 个），会导致大量无效遍历，浪费资源。此时建议在业务层过滤，或通过 Redis 的键命名规范减少无效匹配。
5.4 不要依赖返回结果的顺序
scan的返回结果是基于哈希表的桶顺序，与键的插入顺序无关，且每次遍历的顺序可能不同。业务层不应依赖scan的返回顺序。