redis lua脚本应避免全量遍历keys，改用scan+lua组合并正确解构返回值；优先批量操作如mget；数值过滤宜用zinterstore+zrangebyscore而非sinter；redisshake中必须显式调用shake.call()否则数据丢失；布隆过滤器需均匀哈希函数，不可仅用redis.sha1()；需主动限制keys数量防oom。
Redis Lua脚本里怎么避免全量遍历KEYS做过滤
直接用 KEYS 命令在生产环境做过滤等于自毁——它会阻塞整个 Redis 实例，且无法分页。真实场景必须用 SCAN + Lua 组合，但注意：Lua 里调用 SCAN 返回的是两元素数组（游标、key 列表），不是单个 key 列表。
- 正确写法是先
redis.call("SCAN", cursor, "MATCH", pattern, "COUNT", count)，再解构返回值：local new_cursor = keys[1]; local key_list = keys[2] - 不要在 Lua 循环里反复调用
GET或HGETALL——每次调用都算一次 Redis 命令开销，容易拖慢脚本；应优先用redis.call("MGET", unpack(key_list))批量取值 - 若需按 value 内容过滤（比如只保留 value 包含 "active" 的 key），建议提前约定 value 格式，避免在 Lua 里做
string.find这类高开销操作
多个集合交集+条件过滤时，为什么 ZINTERSTORE 比 SINTER 快得多
ZINTERSTORE 底层基于有序集合的 score 排序合并，时间复杂度接近 O(N)，而 SINTER 在集合大小差异大时可能退化到 O(N×M)。尤其当你要对交集结果再按数值范围过滤（如 “score > 100”），ZSET 天然支持 ZRANGEBYSCORE，不用把全部 member 拉到 Lua 里遍历。
- 用
ZINTERSTORE合并多个 ZSET 后，直接ZREMRANGEBYSCORE temp_key "-inf" "(100"删除不满足条件的数据，比在 Lua 表里for遍历快一个数量级 - 如果原始数据是 SET，但业务需要数值过滤，建议迁移阶段就转成 ZSET，score 设为业务数值（如用户等级、时间戳），否则每次过滤都要查额外哈希或字符串字段
- 注意
ZINTERSTORE的AGGREGATE参数：用MIN可保留各集合中最小 score，适合“所有集合都满足阈值”的场景
RedisShake 的 function 配置里，shake.call() 忘调会导致数据静默丢失
这是最隐蔽的坑：RedisShake 的 Lua 过滤脚本默认不转发任何命令，必须显式调用 shake.call(DB, CMD, KEYS, ARGV) 才会把命令写入目标端。没调用 ≠ 跳过，而是彻底丢弃。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 调试时务必打开
log_level = "debug"，并用shake.log("DB:", DB, "CMD:", CMD)确认脚本执行路径 - 常见错误是加了
if DB == 0 then return end，但忘了在else分支里补shake.call(...)，结果 db 0 被丢弃，其他 db 也全丢了 - 如果要做重写（如给 key 加前缀），别直接改
KEYS数组——它是只读的；要用table.concat拼新 key，再传给shake.call，例如：local new_keys = { "prefix:" .. KEYS[1] }; shake.call(DB, "SET", new_keys, ARGV)
Lua 实现布隆过滤器时，哈希函数不能只用 redis.sha1()
redis.sha1() 输出是 40 字符十六进制串，直接取模会严重倾斜——它本质是字符串哈希，不是均匀分布的整数哈希。真实布隆过滤器需要 k 个独立、均匀、可复现的哈希函数。
- 推荐方案：用
redis.sha1(key)生成摘要后，用不同位段截取（如前 8 字节、中间 8 字节、后 8 字节），再分别tonumber(..., 16) % bit_array_size - 更稳妥的做法是引入预定义常量做扰动，例如：
(tonumber(redis.sha1(key..i), 16) % 1000000) + i * 31，其中i是哈希轮次（0~k-1） - 别在 Lua 里实现 MurmurHash 或 CityHash——Redis 不带这些库，自己写易出错且性能差；优先考虑加载
redisbloom模块，或用 Lua 脚本调用已编译好的模块命令（如BF.ADD）
实际部署时，最易被忽略的是 Lua 脚本的内存限制：Redis 默认单个脚本最大内存 512MB，但超限不会报错，只会触发 OOM kill，表现为 EVAL 命令超时或连接重置。建议在脚本开头加 if #KEYS > 1000 then error("too many keys") end 主动拦截。
