不能用 KEYS+DEL 清理，因 KEYS 全量扫描会阻塞主线程导致服务卡顿；应采用 SCAN 分批扫描、Lua 脚本匹配过期 key（不执行 DEL）、客户端控制节奏的组合方案。
直接用 KEYS 扫描再删所有 key 会阻塞 Redis 主线程，线上环境基本等同于制造故障；真正能用的方案是用 SCAN 分批 + Lua 脚本匹配 + 客户端控制节奏，三者缺一不可。
为什么不能用 KEYS + DEL 一次性清理
因为 KEYS 是全量扫描命令，Redis 单线程执行时会卡住整个服务。哪怕只有几千个 key，也可能导致延迟飙升、超时堆积、下游重试雪崩。官方文档明确标注“KEYS is not recommended for production use”。更糟的是，它不区分是否过期——你删的可能是刚 set 还没来得及 ttl 的有效数据。
SCAN 配合 Lua 脚本只返回待删 key 列表
脚本不做 DEL，只做「查」：遍历当前批次、比对 TTL、收集过期 key。这样脚本执行时间可控，不会拖慢 Redis。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 脚本接收两个参数：
ARGV[1]是扫描的 pattern（如"*"），ARGV[2]是COUNT值（建议 100～500） - 用
redis.call("TTL", key)获取剩余秒数，ttl 表示已过期（注意：-1 是永不过期，-2 是 key 不存在） - 返回格式必须是 Lua table，例如
{cursor, {key1, key2}}，Redis 才能正确解析为数组 - 示例片段：
local cursor = tonumber(ARGV[1]) or 0<br>local count = tonumber(ARGV[2]) or 100<br>local keys_to_del = {}<br>local new_cursor, batch = redis.call("SCAN", cursor, "MATCH", "*", "COUNT", count)<br>for _, key in ipairs(batch) do<br> local ttl = redis.call("TTL", key)<br> if ttl < 0 then table.insert(keys_to_del, key) end<br>end<br>return {new_cursor, keys_to_del}
客户端循环调用并分批执行 DEL
脚本只返回 key 列表，DEL 必须由客户端发起，且每次最多删 1000 个（避免单次命令太重）。同时要检查 new_cursor == 0 来判断是否扫完。
- 每次调用脚本后，拿到
new_cursor和待删 key 列表 - 若 key 列表非空，用
redis-cli --raw -n 0 DEL key1 key2 ...或代码中批量调用DEL - 休眠 10～50ms（比如
time.sleep(0.02)），给 Redis 留出处理其他请求的时间 - 重复直到
new_cursor == 0，或人为中断（比如监控到used_memory_rss下降趋缓）
容易被忽略的边界点
过期 key 不等于「TTL 返回负数」就一定该删——有些 key 可能被显式设置了 EXPIRE 但还没到时间，TTL 暂时为正；而有些 key 根本没设过期时间，TTL 返回 -1，这类不该动。真正要清理的，是 TTL 返回 -2（key 已逻辑删除但还残留）或已确认 TTL < 0 的。另外，Lua 脚本里不能用 os.time() 或网络调用，所有判断必须基于 Redis 内置命令返回值。
