Lua 脚本与函数的内存
Redis 把脚本与函数的内存单独统计：脚本缓存按 SHA1 保存脚本文本，函数库由 FUNCTION LOAD 加载并随数据持久化。这两部分在 INFO memory 里有独立字段，体积通常很小，但客户端若动态拼接脚本文本，缓存条目会只增不减，成为容易被忽略的内存来源。
基本信息
| 脚本字段 | used_memory_lua、used_memory_scripts、number_of_cached_scripts |
|---|---|
| 函数字段 | used_memory_functions、number_of_functions（Redis 7.0 起） |
| 来源 | EVAL/EVALSHA 缓存与 FUNCTION LOAD |
| 生命周期 | 脚本缓存重启即清空，函数库随 RDB/AOF 保留 |
| 清理命令 | SCRIPT FLUSH、FUNCTION FLUSH 与 FUNCTION DELETE |
| 执行保护 | lua-time-limit 限制单次脚本执行时长 |
典型使用场景
- 巡检脚本缓存：缓存条目数长期上涨，说明客户端没有复用同一份脚本体
- 上线前评估：把脚本预加载成固定文本，客户端用 SHA1 调用更省缓存
- 函数治理：FUNCTION LIST 确认加载了哪些库、各自占用多少内存
- 排查 NOSCRIPT 报错：客户端收到该错误，通常是被清理过缓存或实例重启
- 内存归因：脚本内存异常偏高时，先查是否把数据存进了脚本或函数状态
最小示例
最小示例
redis-cli INFO memory | grep -E 'used_memory_lua|used_memory_scripts|number_of_cached_scripts'
redis-cli SCRIPT EXISTS 5f6b1f9c0f1f # 用 SHA1 判断脚本是否还在缓存里
redis-cli SCRIPT LOAD "$(cat script.lua)" # 预加载，之后用 EVALSHA 调用
redis-cli SCRIPT FLUSH # 清空脚本缓存，用 EVALSHA 的客户端会失败
redis-cli FUNCTION LIST # 查看已加载的函数库（Redis 7.0 起）
redis-cli CONFIG GET lua-time-limit # 单次脚本的最长执行时间字段读法
| 字段 | 含义 | 异常信号 |
|---|---|---|
| used_memory_lua | Lua 引擎自身占用 | 相对稳定，随脚本执行小幅波动 |
| used_memory_scripts | 已缓存脚本文本占用 | 持续增长说明脚本体在不断变化 |
| number_of_cached_scripts | 缓存脚本条目数 | 上万条说明客户端没有复用脚本体 |
| used_memory_functions | 已加载函数库占用（7.0 起） | 随发布增长，需要有下线机制 |
| number_of_functions | 已加载函数条目数 | 与预期的库数量不符，要复盘发布流程 |
脚本缓存与函数库是两套机制：脚本缓存重启即失效，用 EVALSHA 的客户端必须保留 EVAL 回退路径；函数库属于部署资产，应纳入版本管理与上线流程。
脚本体内创建的大对象只占用执行期内存，不计入脚本缓存字段，它体现在 used_memory 与峰值上。写脚本时避免一次性构造超大表或做全量遍历。