string操作变快是因为网络io层优化，redis 7.0将read()/write()卸载至独立io线程池，主线程专注串行处理命令，避免系统调用阻塞，小包请求（如get）性能提升显著。
String 操作变快，不是因为命令变了
Redis 7.0 的 GET、SET、INCR 等 String 命令本身逻辑没改，执行时间仍稳定在几微秒。真正提速的是网络 IO 层——主线程不再亲自调用 read() 和 write()，这部分被卸载到独立的 IO 线程池中。
这意味着：高并发下，主线程能更专注地串行处理命令，不会被系统调用卡住。尤其当请求体小（多数 GET 请求包
- 必须显式开启：
io-threads-do-reads yes（默认是no） -
io-threads至少设为 2，否则 IO 线程池不生效 - 未绑定 CPU 核心时，线程调度抖动可能抵消收益；建议用
taskset固定 IO 线程到特定核
内存碎片没减少，但更可控、更可测
Redis 7.0 没新增任何 String 指令，所谓“新指令优化碎片”是误解。所有内存行为改进都来自 SDS 编码策略的自动演进：比如按长度选 sdshdr8/sdshdr16、预分配冗余空间、短字符串（≤44 字节）走 embstr 编码等——这些完全透明，无需用户干预。
但你依然会因写入模式触发隐式浪费：
- 反复
APPEND小数据（如每次 +3 字节），SDS 频繁小幅扩容，积累大量小块冗余 - 先
SET2MB 日志（触发raw编码），再DEL后写入 1KB 字符串，旧大块 malloc 内存无法复用 - 混用
INCR（转int编码）和SET字符串（强制切回embstr或raw），引发一次完整重分配
验证当前编码和真实内存开销，别靠猜
想确认一个 key 是不是真的省内存？不能只看 STRLEN，它只返回字符串内容长度。得用两个命令直击底层：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
OBJECT ENCODING <key></key> 返回当前实际编码：int、embstr 或 raw
MEMORY USAGE <key></key> 返回该 key 占用总字节数（含 redisObject 头 + SDS 头 + 数据 + 冗余空间）
注意：MEMORY USAGE 在集群模式下必须访问 key 实际所在节点，否则返回 0
真正影响性能的，是你怎么用老命令
7.0 的价值不在“加了什么”，而在“让你看清了什么”。它没给你新工具，但把原本黑盒的编码切换、内存分配行为暴露出来——只要你主动查 OBJECT ENCODING 和 MEMORY USAGE，就能定位出那些看似无害、实则悄悄拖慢响应、涨爆内存的操作模式。比如某个高频 APPEND 场景，跑着跑着发现编码从 embstr 变成 raw，MEMORY USAGE 翻倍，那就该换策略了。
