应先用redis-cli --bigkeys扫描定位大key，再通过info memory查看mem_fragmentation_ratio是否超1.5以判断内存碎片，结合memory usage精确测量单key内存占用；同时优化编码阈值、淘汰策略及键名设计。
Redis内存占用过高时，不能只靠删数据或加机器——得从键设计、编码选择、淘汰策略和碎片控制四个层面同步动手，否则容易反复踩坑。
怎么快速定位大Key和低效结构？
盲目调参前先确认问题源头。用 redis-cli --bigkeys 扫描，它会按数据类型统计最大元素（如 Biggest hash found so far 'user:profile'），不阻塞服务；再配合 INFO memory 看 mem_fragmentation_ratio，超过 1.5 就说明内存碎片严重，不是数据多，而是分配不均。
- 避免用
KEYS *查键——它会锁主线程，生产环境禁用 -
SCAN是安全替代，但需客户端做多次迭代，别指望一次扫完 - 对疑似大Key，用
MEMORY USAGE keyname精确看单个键占多少字节，比估算靠谱
为什么改几个配置参数就能省下30%内存？
Redis内部对小数据结构有紧凑编码（如 ziplist、intset），但默认阈值偏高，大量本可压缩的数据被存成普通结构。比如一个只有 5 个字段的 Hash，若每个字段值都短于 64 字节且总字段数 ≤ 512，启用 ziplist 能省掉大量指针开销。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 调低
hash-max-ziplist-entries到 256（默认 512），hash-max-ziplist-value到 64（默认 64，可保持） -
list-max-ziplist-size -2表示最多存 8k 元素才转为链表（比默认 -5 更激进） - 改完要重启或
CONFIG REWRITE，并观察INFO stats中evicted_keys是否突增——说明编码转换太频繁，得回调
淘汰策略选错会导致数据被误删
volatile-lru 只淘汰带 EXPIRE 的键，如果业务里大量缓存没设过期时间，这个策略等于失效；而 allkeys-lru 会无差别淘汰，可能把高频热数据也踢掉。真正关键的是：你的数据有没有自然生命周期？
- 纯缓存场景（如商品页HTML片段）→ 用
allkeys-lfu，它按访问频次淘汰，比LRU更稳 - 带状态的数据（如用户session）→ 必须设
EXPIRE，然后配volatile-ttl，优先删快过期的 - 绝对不能选
noeviction上生产，写入失败报OOM command not allowed when used memory > 'maxmemory'会让上游逻辑崩
内存碎片和压缩不是可选项，是必调项
即使 used_memory 没到 maxmemory，mem_fragmentation_ratio 高也会触发OOM——因为物理内存无法连续分配。Redis 6.2+ 的 MEMORY PURGE 可释放jemalloc缓存，但治标不治本。
- 在
redis.conf开启activedefrag yes，并设active-defrag-threshold-lower 10（碎片率超10%就启动整理） - 字符串值大于 100KB 时，考虑客户端压缩（如用
snappy序列化后再存），但注意CPU开销是否可接受 - 别依赖
redis-cli --in-memory-optimize——它只是重哈希，对内存节省微乎其微，文档里都没提了
最常被忽略的一点：键名本身就在吃内存。一个 user:session:data:123456789 比 us:123456789 多占近一倍空间，而Redis对每个键都要存字符串头、SDS结构、dictEntry指针——这些开销在亿级键规模下就是GB级浪费。
