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 确认：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 执行 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 清理