redis 不支持根据访问频率动态切换淘汰策略，仅允许静态配置一种maxmemory-policy；其淘汰机制是全局统一执行，无热度分析与策略自适应能力，需人工或外部驱动切换。
Redis 本身不支持“根据访问频率动态切换淘汰策略”——它只允许你静态配置一种 maxmemory-policy，运行期间可改，但不会自动感知 key 热度变化而切策略。 想靠 Redis 自己“看到热点就切到 LFU、冷数据多就切回 LRU”，这条路走不通。
为什么不能自动按频率切策略
Redis 的淘汰策略是全局开关，不是 per-key 的自适应逻辑。它在内存不足时统一执行一套规则（比如 allkeys-lfu 就查所有 key 的 counter；volatile-lru 就只看带过期时间的 key 的 lru 字段），没有运行时分析热度分布、再决策该用哪种算法的机制。
常见误解是：既然 LFU 能反映频率，那是不是 Redis 内部会“判断哪个策略更适合当前数据分布”？不会。LFU 的 counter 只服务于 LFU 类策略，对 LRU 或 TTL 策略完全无用；反之亦然。
- 所有策略共用同一套内存触发逻辑（
maxmemory达标 + 写入操作） - 策略一旦生效，就严格按其定义筛选候选 key，不跨策略比较
- 没有内置的“热度分布统计 → 策略推荐”模块，连 INFO 输出里都不提供各策略模拟淘汰效果的对比指标
真正能“响应访问频率”的只有 LFU 类策略本身
如果你的目标是“让高频 key 更难被淘汰”，那不是换策略，而是选对策略并调好 LFU 参数。重点不在“动态切换”，而在“让 LFU 真正反映业务热度”。
关键参数有三个，它们共同决定 counter 如何增长和衰减：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
lfu-log-factor：默认 10，值越小，低频 key 的 counter 上升越快（比如设为 1，刚访问几次 counter 就跳到 10+）；值越大（如 100），高频 key 才能明显拉开差距 -
lfu-decay-time：单位分钟，默认 1，表示每分钟把所有 key 的 counter 按比例衰减一次；设为 0 则永不衰减（易导致旧热点长期霸榜，不推荐） - 初始 counter 值：新 key 插入时
logc不是 0，而是 5 —— 所以它天然比刚被访问一次的 key “更耐淘汰”，但也意味着你需要多次访问才能显著提升 rank
示例：想让“最近 1 小时内高频访问的 key 明显优于昨天的热点”，可调 lfu-decay-time 1（保持默认）+ lfu-log-factor 25（增强区分度），避免小流量 key 过早冲高 counter。
需要策略切换？只能人工或外部驱动
生产中真有场景要“白天用 LFU、夜间批量导入用 LRU”，只能靠运维动作或应用层配合：
- 用
CONFIG SET maxmemory-policy allkeys-lfu或allkeys-lru手动切换，注意这是运行时命令，需权限且影响全局 - 结合监控（如
INFO stats中的evicted_keys、expired_keys）+ 业务节奏（如大促前切allkeys-lfu，导数任务期间切allkeys-random）做定时脚本 - 应用层自己维护热度标签（如用 Sorted Set 存 {key, access_count}），在写入前预判：若 key 是当前 Top 100 热点，则强制
EXPIRE加长 TTL，变相“保活”——这比依赖 Redis 自动策略更可控
别指望 Redis 自己学会看仪表盘调参数。它的 LFU 是稳定可靠的计数器，不是 AI 热度模型。
最容易被忽略的一点：即使你用了 volatile-lfu，如果大量 key 没设过期时间，它们根本不会参与淘汰——此时看似开了 LFU，实际等效于 noeviction（写满就报错）。确认策略生效，第一件事是检查 INFO keyspace 里带过期时间的 key 占比。
