调大lfu-decay-time会让热点key更“耐老”，因为它延长了计数器衰减周期，减少高频访问key的热度被过快抹平，使其在lfu淘汰中更持久。
为什么lfu-decay-time调大会让热点key更“耐老”
Redis的LFU淘汰策略里，lfu-decay-time控制的是计数器衰减节奏：它定义了“每过多少分钟，就对所有key的counter做一次右移1位（等效除以2）或直接减1”的频率。默认值是1，也就是每分钟衰减一次。这意味着一个counter=64的key，6分钟后就可能掉到0——哪怕它每秒都被GET，只要没触发新的增长，热度就会被系统“抹平”。调大这个值，本质是拉长衰减周期，给高频访问留出缓冲窗口。
怎样设置lfu-decay-time才真正生效
光改lfu-decay-time不够，必须同时满足三个条件：
-
maxmemory-policy已设为volatile-lfu或allkeys-lfu（用CONFIG GET maxmemory-policy确认） -
lfu-decay-time未被注释，且值已写入配置（CONFIG GET lfu-decay-time能查到你设的数字） - key本身已被真实访问过（刚SET的key，
OBJECT FREQ返回5是正常的，但不会立即衰减）
常见错误是只改lfu-decay-time却漏掉第一项，结果策略退化为LRU，衰减逻辑压根不运行。
不同业务场景下lfu-decay-time的推荐值
没有万能值，关键看你的热点周期长度：
- 秒杀/活动页类突发流量：
lfu-decay-time 1（保留默认），配合lfu-log-factor 15~20，让新热key快速起量、旧冷key迅速归零 - 日志聚合、报表缓存等小时级稳定热点：
lfu-decay-time 60，避免每小时衰减一次把刚积累的热度清零 - 用户权限token、核心配置等长期高频key：
lfu-decay-time 1440（一天），让热度基本不衰减，只靠lfu-log-factor压制冲顶速度
注意：调大后，INFO memory里的lfu_bypassed可能上升——说明部分低counter key因衰减太慢而长期卡在淘汰候选池外，需结合lfu-log-factor同步微调。
验证调优是否起作用的关键动作
别盯着单个OBJECT FREQ值看涨跌，那只是概率快照。真正有效的验证方式是：
- 持续用
redis-cli --scan --pattern "*" | xargs -L 1 -I {} redis-cli OBJECT FREQ {}抽样一批key，统计counter分布（比如0–10、11–50、51–255各占多少比例） - 对比调参前后，高counter区间（如>100）的key数量是否明显增加且更稳定
- 观察
INFO stats中evicted_keys的淘汰倾向：如果原来频繁淘汰counter=1的临时key，现在更多淘汰counter=0的老冷key，说明衰减变慢已影响实际决策
LFU的衰减不是线性倒计时，而是按固定间隔批量触发；一次CONFIG SET不会重算历史counter，只影响后续更新——所以变化需要时间沉淀，急不得。
