Redis 7.0无“内存分段释放”机制，实际依赖UNLINK异步删除+渐进式拆分（如HSCAN/HDEL分批处理）+配置调优（如增大repl-backlog-size、client-output-buffer-limit）三者协同，否则主从同步仍会阻塞或断连。
Redis 7.0 并没有“内存分段释放”这个内置机制，所谓“分段释放”是误传；真正可用的是 UNLINK + 渐进式拆分 + 配置调优三者组合，否则主从同步仍会断连或延迟飙升。
UNLINK 不等于分段，它只是把删除扔给后台线程
很多人以为 UNLINK 能“分段释放内存”，其实不是：UNLINK 只是把 key 的元数据（如 dictEntry、robj 指针）从数据库中摘除，并把实际内存释放任务交给 lazyfree-thread 异步执行。但对大 Key 来说，后台线程仍要一次性遍历所有元素、归还内存页——这过程本身不拆分，只是不卡主线程。
- String 类型大 value（如 50MB）：
UNLINK立即返回，后台线程释放整块内存，无压力 - Hash/List/Set/ZSet 类型（含数万 field 或 member）：后台线程仍需逐个释放每个子项，若元素极多（比如 200 万），仍可能压垮 lazyfree 线程、堆积未释放内存
- 主从同步不受影响？错。主节点执行
UNLINK后，该操作仍以一条DEL命令形式写入 AOF 并同步到从节点——从节点收到后照样得执行一次同步删除，照样阻塞
主从同步中真正有效的拆分必须在主节点上渐进执行
要避免复制流被一个大 Key 卡死，唯一可靠方式是：在主节点上用游标命令分批读取 + 写入新结构 + 清理旧字段，让每一步都变成小命令进入复制流。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 对大 Hash：
HSCAN myhash 0 COUNT 50拉出 50 个 field，HSET myhash:shard01 ...写入新 key，再HDEL myhash f1 f2 ...删除这 50 个——每轮最多 50 个字段，不超网络包限制 - 对大 ZSet：
ZSCAN myzset 0 COUNT 100+ZADD myzset:part1+ZREM myzset，注意ZREM支持批量删，但别一次删超 500 个，否则从节点同步时仍可能超时 - 必须在主节点执行：从节点只读，不能参与任何写逻辑；所有
HSET/HDEL都走复制流，确保从节点状态最终一致 - 加
SLEEP 0.005（如用redis-cli --eval调 Lua）：防止连续高密度命令打满主节点 CPU 和复制缓冲区
关键配置必须提前调大，否则 UNLINK 也救不了
即使用了 UNLINK，如果主从复制缓冲区太小，一个大 Key 的同步仍会触发断连。这些配置必须在问题出现前就设好：
-
client-output-buffer-limit slave 512mb 128mb 60：把默认的 256MB/64MB 提高一倍，防止单次 bulk reply 打穿 -
repl-backlog-size 1024mb：增大复制积压缓冲区，避免从节点重连时因 offset 脱离而触发全量同步（全量=又来一遍大 Key） -
lazyfree-lazy-server-del yes：开启 rename、flushdb 等隐式删除的异步化，但注意——它不影响主从同步中的DEL命令行为 - 禁用
CONFIG SET动态改maxmemory-policy：该命令会阻塞主线程，且切换瞬间可能批量淘汰，引发二次带宽洪峰
删除后内存不降？不是没释放，是没还给 OS
执行完 UNLINK 或拆分清理后，INFO memory 中 used_memory_rss 可能长期不下降，这不是 bug：
- jemalloc 默认不立即归还空闲内存页给操作系统，而是缓存起来供后续分配复用
- 确认是否真释放：看
used_memory（Redis 逻辑内存）是否下降，而非rss - 强制归还：仅限低峰期手动执行
MEMORY PURGE，但不要依赖它做日常治理 - 真正要盯的是
mem_fragmentation_ratio：持续 > 1.5 说明碎片严重，大 Key 拆分后建议重启实例（滚动重启）来彻底整理内存
