Redis SCAN 扫描为什么仍会拖慢业务：游标、批量大小与渐进式巡检边界

线上排查大 Key、缓存前缀或过期数据时，把 KEYS 换成 SCAN 只是把一次重操作拆成了许多小调用，并没有消除完整遍历的总成本。真正容易误判的地方有两个：COUNT 不是固定返回条数，游标回到 0 才能说明这一轮遍历结束；数据在扫描期间发生变化时，结果也不能当作一致性快照。

SCAN 适合把键空间巡检做成可暂停、可限速的渐进任务。用 MATCH 或 TYPE 缩小范围，用较小的 COUNT 控制单次压力，持续推进游标到 0，再用去重和复查处理变化中的数据。

SCAN 的 COUNT 为什么不是固定返回条数

SCAN 的基本形式是 SCAN cursor [MATCH pattern] [COUNT count] [TYPE type]。例如只巡检用户缓存键，可以先限定命名模式：

redis-cli SCAN 0 MATCH 'cache:user:*' COUNT 200

这里的 COUNT 200 更像一次调用的工作量提示。Redis 会返回“下一个游标”和本轮找到的键，实际数量会受编码、过滤命中率以及当前键空间状态影响；命中少不等于遍历完成。MATCH 先过滤名称，TYPE 还能按 string、hash、set 等类型缩小结果，因此同样的 COUNT 在不同条件下可能呈现完全不同的返回量。

核对时至少记录两项：返回的游标和返回键的数量。即使这轮列表为空，只要游标仍然不是 0，下一轮也要把新游标传回 SCAN。

游标 0 代表什么，不代表什么

游标是 Redis 维护的遍历位置，不是业务分页页码，也不应被程序自行加一。最小循环可以写成下面这样，重点是把返回游标覆盖到下一次请求：

cursor=0
while :; do
  result=$(redis-cli --raw SCAN "$cursor" MATCH 'cache:user:*' COUNT 200)
  cursor=$(printf '%s\n' "$result" | sed -n '1p')
  printf 'next_cursor=%s\n' "$cursor"
  [ "$cursor" = "0" ] && break
done

生产实现通常会直接使用客户端返回的数组结构，不必依赖文本拆分。无论使用哪种语言，都应把起始游标、结束游标、过滤条件、命中数和单轮耗时写入巡检记录。这样才能区分“本轮没有命中”和“本轮还没走完”。

为什么一次 SCAN 不能当一致性快照

当键空间在遍历期间保持不变时，游标回到 0 可以完成一次完整迭代；但真实业务通常会持续写入、过期和删除。变化发生在扫描前后时，结果可能包含新增键、漏掉随后出现的键，或者在不同轮次观察到同一个键。这个边界不是 COUNT 能解决的，SCAN 本身也不是快照接口。

因此，线上清理或巡检最好采用三段式约束：扫描阶段只收集候选；判断阶段再次确认键的类型、版本或业务状态；变更阶段使用幂等动作并保留复查记录。把它当成渐进巡检，对可能变化的前缀安排第二轮检查，比把一次长扫描当成全量快照更稳妥。

线上巡检如何选择 COUNT、MATCH、TYPE

如果只是想“更快扫完”，盲目把 COUNT 从 200 调到 10,000 往往会让单次事件循环工作变重。更可控的做法是先缩小 MATCH，能确定类型时再加 TYPE，然后观察每轮耗时和业务延迟。完整遍历的总复杂度仍与元素数量相关，所谓不阻塞更准确地说是把压力摊开，而不是让成本消失。

常见问题

SCAN 返回空数组，是不是扫描结束了？

不一定。先看返回游标；只有游标为 0 才完成这一轮迭代，过滤条件严格时中途为空很常见。

COUNT 能不能保证每轮返回固定数量？

不能。它主要提示单次工作量，实际返回量会受数据结构和 MATCH、TYPE 过滤影响。

SCAN 能完全避免线上卡顿吗？

不能保证。它把完整遍历拆成多次调用，但总工作仍然存在；应降低单轮 COUNT、避开高峰并监控延迟。

把 SCAN 用成巡检工具时，记住三个判断就够了：COUNT 控制单轮节奏，游标 0 判断本轮结束，数据变化决定是否需要去重和复查。这样既能避免 KEYS 式的长时间单次操作，也不会把渐进遍历误当成快照。