Redis内存持续上涨可能源于Lua脚本中未设置过期时间的临时键，如set、hset、zadd写入后遗漏expire，导致“孤儿键”累积；需用redis-cli --scan结合object freq和ttl定位，并按业务语义修复。
Redis内存持续上涨但没发现大Key？先查Lua脚本里有没有漏掉expire
Redis本身不会因Lua脚本直接导致内存泄漏，但脚本中创建的临时键（比如用set或hset写入）若没配expire，就会永久滞留——尤其在高频调用场景下，这类“孤儿键”会不断累积，表现为内存稳步上涨，容易被误判为内存泄漏。
Lua脚本里哪些操作容易埋雷？重点关注这三类写入
Redis Lua沙箱禁止执行expire以外的后台命令，但允许写入数据。以下写法极易产生长期存活的临时键：
-
redis.call('set', 'tmp:'..KEYS[1], 'value')—— 没跟redis.call('expire', ...)，键永不过期 -
redis.call('hset', 'cache:'..ARGV[1], 'field', ARGV[2])—— 哈希表本身不支持过期，得靠外层key控制生命周期 -
redis.call('zadd', 'sorted_tmp_'..os.time(), 1, 'item')—— 用时间戳拼key看似唯一，但没清理逻辑，积压后成隐患
怎么快速定位问题脚本？用redis-cli --scan + object freq交叉验证
单纯看内存占用没用，关键要识别“不该存在却长期存活”的键。操作步骤如下：
- 用
redis-cli -a <password> --scan --pattern "tmp:*"</password>扫描疑似临时前缀的键 - 对抽样结果执行
object freq <key></key>：返回(integer) 0说明几乎没被访问，大概率是废弃键 - 再用
ttl <key></key>确认是否真的没设过期——返回-1（永不过期）或-2（key不存在）都要警惕 - 结合
script debug yes开启调试后复现请求，观察脚本实际执行路径（注意：生产慎开，仅限排查）
修复方案不是加expire就完事，得匹配业务语义
硬塞expire可能引发竞态或数据错乱。正确做法是：
- 临时缓存类：统一用
setex或psetex替代set+expire，避免两步操作的窗口期 - 哈希/集合类：把整个结构放在一个带过期的key下，别单独给字段设TTL（Redis不支持）
- 需要定时清理的：改用
redis.call('del', 'tmp_key')显式删除，比依赖过期更可控 - 所有
eval调用点必须检查脚本源码——别信“这个脚本很久没动过了”，高频路径的微小变更影响巨大
最麻烦的情况是多个Lua脚本共享同一组临时key命名空间，又各自管理生命周期。这时候光修一个脚本没用，得拉通梳理全链路的key生成和销毁契约。
