lfu-log-factor 调整的是 LFU 计数器增长概率曲线斜率，非灵敏度；值越小，低频 key 越易被识别，值越大，高频 key 增长越慢且更难达上限 255。
lfu-log-factor 不是“调灵敏度”，而是改增长曲线斜率——值越小，低频 key 越容易被识别；值越大，高频 key 越难涨上去。
为什么改了 lfu-log-factor，OBJECT FREQ 还是不动
常见错误是只改配置却没触发访问。LFU 计数器只在 GET、SET 等访问操作时按概率更新，不是实时刷新的。刚设完 lfu-log-factor 100 就跑 OBJECT FREQ mykey，大概率看到还是 5 或 0——它根本还没被访问过。
- 新 key 的初始计数器固定为
LFU_INIT_VAL（默认 5），不是 0，所以第一次GET后也不一定 +1 - 增长是概率行为：
lfu-log-factor越大，当前 counter 对应的增长概率越低。比如 counter=5 时，factor=100 的增长概率约 0.002，平均要访问 500 次才可能触发一次 +1 - 确认是否真正启用了 LFU：先检查
CONFIG GET maxmemory-policy是否返回volatile-lfu或allkeys-lfu，否则所有 LFU 配置都不生效
lfu-log-factor 取值怎么选：看你的热点分布形态
这个参数本质是在“早识别冷 key”和“稳住真热 key”之间做权衡，没有通用最优值。
- 业务有大量中低频 key（如用户个性化配置），且偶尔冒出新热点（如活动页）→ 用
lfu-log-factor 1~5：让新 key 的 counter 快速从 5→6、6→7，避免被误淘汰 - 核心数据高度集中（如商品 ID、登录 token），且长期稳定高频 → 用
lfu-log-factor 50~100：压制高频 key 的涨幅，防止它们早早冲到 255 占满上限，挤掉中频 key - 默认值
10是平衡点，但只适合访问分布较均匀的场景；一旦你观察到INFO memory中lfu_bypassed值持续偏高（说明很多 key 因 counter 太低没参与淘汰采样），就得调小 factor
别拿 OBJECT FREQ 做精确判断，它只是快照
OBJECT FREQ 返回的是当前内存里的 counter 快照，但它受三个隐藏变量影响：后台衰减是否刚执行、counter 是否已饱和（255）、以及该 key 最近是否被访问过触发增长。它不是日志，也不是累加器。
- 看到某个 key 长期返回 255？说明它持续高频，但不等于“访问了 255 次”，可能是 10000 次后卡在了上限
- 刚
SET的 key，OBJECT FREQ返回 5 是正常行为，不是 bug - 想验证 factor 效果，不要单看一个 key，而要看整体趋势：用
redis-cli --scan --pattern "*" | xargs -L 1 redis-cli OBJECT FREQ抽样一批 key，统计分布（比如 counter ≤10 的占比），再对比调整前后的变化
真正容易被忽略的点是：lfu-log-factor 和 lfu-decay-time 必须配合看。单独调小 factor 让新 key 易升温，但若 decay-time 还设成 1（每分钟衰减一次），热度又会迅速流失——这两个参数是一体两面，改一个之前，先看另一个当前值是多少。
