Redis 7.0 的 Functions 不参与内存淘汰，因其作为元数据存储于独立内存区，不计入 used_memory_dataset；淘汰机制仅作用于键值数据，而 Functions 的内存开销源于函数体大小及运行时临时数据。
Functions 不参与内存淘汰
Redis 7.0 的 Functions（通过 FUNCTION LOAD 注册的函数库）不占用可淘汰的内存空间，也不受 maxmemory 和淘汰策略（如 allkeys-lru）影响。它们被当作 Redis 运行时的“元数据”而非“数据”，存储在独立于键空间的内存区域中。
为什么 Functions 不会被淘汰
原因很直接：Functions 是服务端逻辑定义，不是用户存入的键值对。Redis 的内存淘汰机制只作用于数据库中的 key-value 数据（包括 String、Hash、List 等），而 Functions 库是加载到 Lua 沙箱环境中的代码结构，生命周期与 Redis 实例绑定，不计入 used_memory_dataset。
-
INFO memory中的used_memory_dataset和used_memory_dataset_perc均不含 Functions 占用内存 - 执行
MEMORY USAGE查任意 key，不会体现函数库开销 - 即使触发
maxmemory限流或 OOM，Functions 仍可正常FCALL，不会被驱逐或卸载
但要注意真实内存开销来源
Functions 本身不淘汰，不代表它没内存成本——真正吃内存的是运行时行为：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 函数体过大（比如嵌入了长字符串常量、大 table 初始化）会增加初始化内存占用，但只在
FUNCTION LOAD时一次性分配，后续复用不增长 - 函数内调用
redis.call("hgetall", keys[1])等命令返回大量数据，这些结果会进入 Lua 栈，可能触发临时内存峰值——但这是运行时瞬态，不属于“淘汰对象” - 频繁调用含循环/递归的函数，可能导致 Lua 栈溢出（报错
ERR Error running script (call to f_): @user_script:xx: stack overflow），这不是内存淘汰，而是执行中断
对比 EVAL 脚本的内存行为更清晰
旧式 EVAL 脚本虽也不被淘汰，但它的 SHA1 缓存（由 SCRIPT LOAD 生成）是纯内存缓存，重启即丢；而 FUNCTION LOAD 注册的函数写入 AOF/RDB，重启后重载进内存——这个“重载”过程不走淘汰路径，是初始化阶段强制加载的。
所以不必担心 Functions 被 volatile-lfu 清掉，但得小心别把几 MB 的 JSON 字符串硬编码进函数体里——那部分内存从加载那一刻起就固定占着，且无法被任何淘汰策略回收。
