Redis无法直接查看Lua脚本内存占用，其缓存不计入used_memory统计；真正影响内存的是执行时的临时对象，需通过慢日志、命令统计和客户端日志等间接方式监控脚本行为。
Redis不提供直接查看Lua脚本内存占用的命令
你无法通过 INFO memory 或 MEMORY USAGE 查到某个 Lua 脚本本身占了多少内存。Redis 把已加载的脚本缓存在内部结构（server.lua_scripts 字典）里，但这些对象不暴露为可查 key，也不计入 used_memory 的常规统计项——它们的内存开销被归入“元数据开销”或“其他内部结构”，混在 used_memory 里无法剥离。
实际影响更大的是脚本执行时的临时内存：比如 table.new(10000, 0)、拼接大字符串、或 redis.call("SMEMBERS", "huge-set") 返回几 MB 数据后在 Lua 里遍历——这部分会真实推高 RSS，但属于运行时堆栈，脚本结束后即释放，无法用静态方式监控。
间接判断脚本缓存是否成为内存负担
虽然看不到单个脚本大小，但可以观察整体缓存行为是否异常：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
-
SCRIPT LOAD每次调用都会把脚本文本完整存进内存，重复加载同一逻辑（尤其没做 SHA 校验去重）会导致冗余副本 - 用
SCRIPT EXISTS批量检查已加载脚本数量：SCRIPT EXISTS script1 script2 ... script100，若返回大量1，且总数持续增长，说明客户端未复用EVALSHA - 对比
INFO commandstats中cmdstat_script_load的调用频次和cmdstat_evalsha——如果前者占比 >5%，基本意味着脚本管理失控 - 注意
used_memory_peak是否在批量上线新服务后明显跳升，再结合部署时间点反查是否集中SCRIPT LOAD了大量长脚本
真正该监控的是脚本执行行为，而非脚本本身
脚本缓存内存本身通常很小（几百字节/个），危险来自执行过程。重点盯住这些信号：
- 慢日志里出现
EVAL或EVALSHA耗时接近lua-time-limit（默认 5000ms），说明脚本正在霸占单线程 -
INFO stats中的total_commands_processed突降 +rejected_connections上升，可能是脚本超时触发 busy 状态，阻塞新连接 -
redis.call()调用次数超过 5 次的脚本，实测延迟增幅超 40%，应拆分或改用原生命令组合 - 脚本里用了
KEYS、HGETALL、SMEMBERS且没加COUNT限制，极易在数据增长后突然爆内存
想定位具体哪个脚本有问题？靠日志+客户端配合
Redis 服务端不记录脚本内容，只能靠外部手段关联：
- 启用慢日志：
CONFIG SET slowlog-log-slower-than 10000（单位微秒），确保捕获 >10ms 的EVALSHA - 在客户端调用
EVALSHA前，统一打日志：例如"EVALSHA 2e8b4a9d7f (v2.1.0 stock_deduct) with keys [order:123]"，把 SHA 和业务语义绑定 - 用
SCRIPT DEBUG YES开启调试模式（仅限开发环境！），此时redis-cli monitor会显示脚本内每行执行耗时，但生产禁用 - 定期导出所有已加载脚本：
SCRIPT FLUSH前先用SCRIPT KILL（只对只读有效）+ 客户端缓存 SHA 列表，再通过SCRIPT LOAD重建，过程中记录每个脚本长度（string.len(script_text)）
脚本缓存的内存不可见，但它的行为可见；与其纠结“它占了多少”，不如紧盯“它干了什么”。真正压垮 Redis 的，从来不是那段被缓存的 Lua 字符串，而是它在单线程里循环一百万次的那一刻。
