redis本身不降低数据库访问压力，它只是缓存层；真正起作用的是「淘汰策略 + 合理的缓存使用方式」共同把无效/冷数据踢出去，让有限内存始终留给可能被再次访问的热数据——从而提升缓存命中率，间接减少打到数据库的请求量。
直接说结论：Redis 本身不降低数据库访问压力，它只是缓存层；真正起作用的是「淘汰策略 + 合理的缓存使用方式」共同把无效/冷数据踢出去，让有限内存始终留给可能被再次访问的热数据——从而提升缓存命中率，间接减少打到数据库的请求量。
为什么选错淘汰策略会让数据库压力更大
比如用 noeviction 策略，内存一满就拒绝写入，应用层若没做降级或 fallback，就会直接查库；又或者误配成 volatile-random，却给所有 key 都设了 TTL，结果刚缓存的热点商品详情被随机干掉，下次请求照样穿透到 MySQL。
- 命中率掉 10%，数据库 QPS 可能涨 30% 以上（尤其在读多写少场景）
-
volatile-ttl在批量设置相同 TTL 的场景下，容易引发缓存雪崩——大量 key 同时过期 + 淘汰，瞬间击穿到库 -
allkeys-random完全无视访问模式，对电商首页、用户画像这类强热点业务几乎无保护能力
LRU 和 LFU 在真实业务中怎么选
不是看文档里“LFU 更准”就盲目切过去。关键看你的数据访问有没有明显的长尾分布：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
allkeys-lru：适合访问时间局部性明显但频率波动大的场景，比如新闻 Feed、临时会话 token。Redis 近似 LRU 的采样机制（默认 5 个 key 中挑最久未用的）开销小、响应快 - 用
allkeys-lfu：适合稳定热点长期存在，且冷热界限清晰的场景，比如商品详情页 ID、热门短视频 ID。注意要调低lfu-log-factor（默认 10）来加快衰减，否则早期高频访问的 key 会长期卡在内存里 - 别用
volatile-lfu做通用缓存：如果部分 key 忘记设 TTL，它们就永远进不了淘汰池，最终挤占内存却不参与淘汰
配置后必须验证的三件事
光改 maxmemory-policy 不顶用，得确认策略真正在生效：
- 执行
INFO memory，检查mem_allocator是不是jemalloc（碎片率高时会影响实际可用内存） - 观察
evicted_keys计数是否持续增长，同时expired_keys增速是否合理——如果前者为 0 而后者暴涨，说明淘汰根本没触发，可能是maxmemory设得太大或压根没开 - 用
redis-cli --bigkeys扫一遍，确认没有单个 >1MB 的String或含上万字段的Hash：大 key 会拖慢淘汰过程，甚至导致单次淘汰耗时超 100ms，影响主线程响应
最容易被忽略的一点：淘汰策略只管“删谁”，不管“删得够不够快”。如果 hz 参数太低（默认 10），Redis 定期删除过期 key 的扫描频率就跟不上写入节奏，会导致内存虚高、淘汰滞后——这时候即使策略选对了，数据库压力该上来还是会上来。
