Redis内存飙升主因是少数大key而非小key过多；优先用redis-cli --bigkeys定位显性大户，再以MEMORY USAGE精准验证，必要时用rdb-tools分析RDB文件，并排查过期key积压与内存碎片问题。
Redis 内存持续飙升，核心问题往往不是“小 key 太多”，而是少数几个大 key 在悄悄吃掉内存。直接扫全量 key 或硬查 MEMORY USAGE 不仅慢，还会阻塞服务——尤其在千万级 key 的生产环境，这等于主动制造故障。
优先用 redis-cli --bigkeys 快速定位“显性大户”
这是最轻量、最安全的起点，不写脚本、不装工具，一条命令就能筛出每种类型里最可疑的 key：
- 它按数据类型分组（String/Hash/List/Set/ZSet），只返回元素数或字节数最多的那一个，不遍历全部 key
- 加 -i 0.1 参数可大幅降低影响：每扫描 100 个 key 暂停 0.1 秒，适合高峰期外的从库或低峰期主库
- 输出示例中 “Biggest hash found 'user:profile:123' has 48291 fields” 就是强信号，立刻记下这个 key 名，下一步精准测内存
对疑似 key 用 MEMORY USAGE 精确验证实际占用
--bigkeys 只看元素数或字符串长度，但真实内存开销还包含结构头、编码冗余、指针等。必须用 MEMORY USAGE 确认：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 执行 MEMORY USAGE user:profile:123，返回值单位是字节（如 8367254 = 约 8.4MB）
- 注意：对 Hash/List 等复合结构，该命令返回的是估算值（基于抽样），但足够判断是否超阈值（String >10KB、集合 >5000 元素且总内存 >100KB 就该拆）
- 若返回异常高（比如单个 key 占几百 MB），基本可锁定为问题源头，不用再往下扫
需要全量分布？用 rdb-tools 解析 RDB 文件（避开运行时干扰）
当 --bigkeys 找不到明显目标，或怀疑有“隐藏大户”（比如 key 命名规律性强但单个不大、总量惊人），就得脱离运行实例，分析快照：
- 先确保 Redis 已配置 save 或 bgsave 生成最新 RDB 文件（如 dump.rdb）
- 用支持 RDB 12 格式的工具（Redis 7.4+ 必须选新版 rdbtools 或 redis-rdb-cli），执行：
rdb -c memory dump.rdb > memory.csv - 导出 CSV 含字段：db、type、key、size_in_bytes、encoding —— 导入 ClickHouse 或 Excel，按 size_in_bytes 降序排列，一眼揪出 Top 100 占用者
别漏掉“伪大 key”：过期 key 积压和内存碎片
有时 used_memory 高，但查不出大 key，可能是这些隐形因素：
- 检查 INFO memory 中 expired_keys 和 evicted_keys 计数：如果 expired_keys 很大但 evicted_keys 几乎为 0，说明过期 key 没被及时清理（Redis 会惰性删除 + 定期抽样），积压后仍占内存
- 看 mem_fragmentation_ratio：若远高于 1.5（比如 2.3），说明内存碎片严重，即使总用量不高，可用连续内存也不足，容易触发 OOM
- 此时应考虑重启（需主从切换或读写分离配合），或调大 maxmemory-samples 加速过期 key 清理
