KEYS *在Lua脚本中仍会阻塞整个Redis实例，因其单线程特性导致全量遍历无法中断；SCAN是唯一安全替代，但7.0前Lua中不支持MATCH/COUNT参数，需客户端分批处理或升级版本。
KEYS * 在 Lua 脚本里会直接阻塞整个 Redis 实例
Redis 是单线程执行命令的，KEYS * 会遍历全部键空间，数据量稍大（比如几万 key）就可能卡住几百毫秒甚至秒级。这个操作在 Lua 脚本里不会“变快”，反而更危险——它发生在原子上下文中，无法被中断、没有进度反馈、不区分冷热数据。一旦触发，所有后续请求排队等待，客户端超时、连接堆积、监控报警全来。
SCAN 是唯一可行替代，但 Lua 里用法受限
SCAN 本身是游标分批、可控时间的命令，但 Redis 7.0 之前版本的 Lua 环境中，redis.call("SCAN", cursor, "MATCH", pattern) 不支持 "MATCH" 和 "COUNT" 参数；你只能传两个参数：cursor 和 count，没法指定匹配模式。常见翻车点是写成：
redis.call("SCAN", "0", "MATCH", "user:*")这会报错 (error) ERR unknown command 'SCAN' 或参数个数错误。正确写法（7.0 以下）只能靠客户端先算好 key 列表，或改用服务端预置的固定前缀扫描逻辑。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Redis 7.0+ 才支持
redis.call("SCAN", cursor, "MATCH", pattern, "COUNT", count) - 集群模式下，
SCAN只作用于当前节点，不能跨 slot 汇总结果 - 脚本里调
SCAN循环必须手动管理游标，且每次调用仍是完整命令开销，不宜高频使用
脚本里拼 KEYS 字符串等于白忙活
有人想绕过限制，在脚本里拼出 "KEYS user:*" 再用 loadstring 或 redis.call("EVAL", ...) 动态执行——这完全不可行。Redis 的 Lua 解释器禁止任何运行时代码生成，loadstring 不存在，redis.call("EVAL", ...) 也会因权限/语法问题失败。更关键的是，即使能跑，也违背了集群对 KEYS 的静态分析要求：所有 key 必须显式出现在 KEYS 数组里，否则直接报 ERR bad lua script。
真正该做的：把扫描逻辑移出 Lua
批量查 key 这类操作本质不是原子性需求，而是运维或业务批量任务，不该塞进 Lua 脚本。正确路径是：
- 用客户端调
SCAN分批拉 key（支持MATCH），再按需发DEL、UNLINK等命令 - 如果必须原子删前缀 key，用预编译脚本 + 固定
KEYS数组，例如EVAL "... SCAN ..." 1 prefix:lock，但前提是 prefix 已通过{}对齐 slot - 避免在脚本里做“查全量 → 过滤 → 操作”的事，这会让 Redis 承担本该由应用层完成的数据筛选工作
最易被忽略的一点：哪怕脚本只调一次 KEYS，只要它进了生产集群，就可能在某个高峰时刻成为压垮服务的最后一根稻草——而这个问题在线下单机环境永远暴露不出来。
