Redis 大 Key 通常是指 Value 体积过大，例如 String 超过 10KB、集合类型元素数量超过 5000 等；这类 Key 往往会引发内存分布不均、性能下降、网络阻塞以及主从复制同步风险。排查时更推荐使用 redis-cli --bigkeys 做采样扫描，而不是直接全量遍历。
redis-cli 里查不出大 Key，别硬扫
如果直接用 redis-cli 连接 Redis 实例，先执行一遍 KEYS *，或者依赖 SCAN 把所有 key 逐个扫描出来，再挨个用 MEMORY USAGE 统计大小，实际效果通常并不好：不仅效率很低，还可能阻塞主线程。特别是当 key 数量超过 10 万以后，这种排查方式基本就不具备实际操作价值了。更棘手的是，MEMORY USAGE 对某些复杂数据结构的统计并不完全准确，比如 field 数量很多的 HASH，返回结果就可能存在偏差，进而影响对 Redis 大 Key 的判断。
更高效、也更适合线上排查的方式，是先放弃逐个精确测量，改为采样扫描 + 分类统计：
- 用
redis-cli --bigkeys快速找出疑似大 Key（会按数据类型分组统计最大的 key，适合做大 Key 排查，不建议直接全量遍历） - 配合
redis-cli --memkeys（Redis 7.0+）或第三方工具如redis-rdb-tools解析 RDB 文件，进一步查看更准确的 Redis 内存占用分布 - 如果已经明确业务模块，优先检查高频写入的 key 前缀，例如
user:session:*、cache:report:*，再有针对性地执行MEMORY USAGE
maxmemory 设置不生效？检查配置加载路径和运行时状态
如果你在 redis.conf 中配置了 maxmemory 2gb，但通过 redis-cli INFO memory 看到 used_memory_human 明显超过这个值，通常说明 Redis 内存限制配置并没有真正生效。常见原因主要有三个：
redis-server启动时没有指定当前配置文件，实际加载的可能仍是默认配置（检查启动命令是否带了-c /path/to/redis.conf）- 配置被运行时命令覆盖：例如执行过
CONFIG SET maxmemory 0（表示取消内存限制），需要通过CONFIG GET maxmemory确认当前生效值 - 在 Docker 容器环境中配置挂载失败：检查
docker inspect输出中的Mounts，确认是否真的映射到了容器内的/usr/local/etc/redis/redis.conf路径
验证方法并不复杂：执行 redis-cli CONFIG GET maxmemory，返回值必须是非零正整数，而且单位是字节（例如 "2147483648" 就表示 2GB）。
allkeys-lru 不等于“自动清理”，它只在写操作触发时才淘汰
即使设置了 maxmemory-policy allkeys-lru，但 Redis 内存仍持续增长，也不代表淘汰策略失效，而是因为它的触发条件没有满足。LRU 内存淘汰机制通常只会在以下场景下生效：
- 当新的写入命令（如
SET、HSET、LPUSH）导致内存即将超出maxmemory限制时，Redis 才会主动淘汰旧 key - 读操作（如
GET、HGETALL）不会触发淘汰，即使当前内存已经接近或达到上限也一样 - 如果业务流量几乎都是读请求，或者写入频率非常低，那么 Redis 淘汰机制就会处于“沉睡”状态，内存自然不会主动下降
因此，不能把它理解为类似 GC 的定时自动清理机制。如果发现 Redis 内存长期处于高位却没有明显回落，就要进一步确认是否存在持续写入，以及淘汰后是否又被新数据快速填满。这时还需要检查业务逻辑是否反复写入同一批 key，或者 key 设计本身存在问题，例如把大量日志数据持续堆积到一个 LIST 中。
volatile-* 策略要求你主动设过期时间，否则无效
如果选择了 volatile-lru，却发现没有任何 key 被淘汰，大概率不是 Redis 配置异常，而是因为这些 key 根本没有设置过期时间。volatile-* 系列淘汰策略只会作用于已经设置了 EXPIRE 或 PEXPIRE 的 key，其他未设置过期时间的 key 会被视为“永久数据”，不会参与淘汰。
检查方法很直接：执行 redis-cli TTL some_key，如果返回 -1（永不过期）或 -2（key 不存在），那它都不是当前策略下的淘汰目标。临时补救方案可以是批量补充过期时间：
redis-cli --scan --pattern "user:*" | xargs -n 1 -I {} redis-cli EXPIRE {} 3600但更重要的还是从代码层面保证写入时就携带过期时间，例如配合 EXPIRE，或者直接使用 SETEX，而不是等到内存上涨后再被动修补。
Redis 内存占用过高最难处理的地方，往往不在于配置项本身，而在于“淘汰”和“过期”其实是两套彼此独立的机制——前者解决空间问题，后者控制数据时效；两者叠加后，最终行为取决于是否同时满足各自的生效条件，比如既需要写操作触发淘汰，又要求 key 本身带有过期时间。只要漏掉其中任意一环，Redis 内存淘汰机制就很容易形同虚设。
