Redis 7.0 的 String 类型未新增任何操作指令，所有内存优化均源于 SDS 编码策略的自动演进，如按长度动态选用 sdshdr8/sdshdr16 及预分配冗余空间，无需用户干预。
Redis 7.0 的 String 类型没有新增操作指令，所谓“新指令优化内存碎片”是常见误解。 它的内存优化完全来自底层 SDS 编码策略的自动演进，而非用户可调用的新命令。
为什么没有新增 String 指令？
Redis 7.0 对 String 的改进是纯内部机制升级，不暴露新命令。官方未添加如 SETMEMOPT 或 STRCOMPACT 这类接口——所有优化都由 Redis 自动触发，开发者无需、也无法手动干预。
-
SET、GET、INCR等基础命令行为与 6.x 完全一致，协议层无变更 - 所谓“优化内存碎片”，本质是
SDS根据字符串长度动态选择sdshdr8/sdshdr16等头结构，并按规则预分配冗余空间（ - 短字符串（≤44 字节）仍走
EMBSTR编码：RedisObject和 SDS 数据连续分配，天然零碎片
哪些操作会意外加剧内存碎片？
不是指令“新不新”的问题，而是你如何用老指令触发不利编码路径。以下行为在 7.0 中依然会导致隐式内存浪费：
- 反复对同一 key 执行
APPEND小数据（如每次追加 3 字节），可能使 SDS 频繁小幅扩容，积累大量小块冗余空间 - 用
SET写入超长字符串（如 2MB 日志），触发RAW编码 + 大块 malloc，后续若DEL后又写入中等长度值，旧大块内存无法复用 - 混合使用
INCR和SET操作同一 key：数值型INCR可能让 Redis 内部转为INT编码，但后续SET字符串会强制切换回EMBSTR或RAW，引发一次内存重分配
怎么验证当前 String 的实际编码和内存开销？
别猜，用 OBJECT ENCODING 和 MEMORY USAGE 直接看真实状态：
127.0.0.1:6379> SET foo "hello" OK 127.0.0.1:6379> OBJECT ENCODING foo "embstr" 127.0.0.1:6379> MEMORY USAGE foo (integer) 56
-
OBJECT ENCODING返回int/embstr/raw，明确当前编码方式 -
MEMORY USAGE显示该 key 占用总字节数（含 RedisObject 头 + SDS 头 + 数据 + 冗余空间），比STRLEN更真实 - 注意：
MEMORY USAGE在集群模式下需确保访问的是实际存储该 key 的节点，否则返回 0
真正影响内存碎片的是数据写入模式和生命周期管理，不是等一个“新指令”来救场。7.0 的价值在于让这些模式下的隐式行为更可控、更可测——但前提是你得主动去看 OBJECT ENCODING 和 MEMORY USAGE，而不是默认它“应该没问题”。
