生产环境 slowlog-max-len 应根据实际慢命令峰值动态设置，建议先用 SLOWLOG LEN 和 SLOWLOG GET 观察洪峰，中小流量业务至少设为单峰预估量的 2–3 倍；需权衡内存开销（每条约 200–400 字节），避免挤压键值存储；务必 CONFIG REWRITE 持久化配置，并配合 slowlog-log-slower-than 收敛、定时外卸和告警形成防丢失闭环。
slowlog-max-len 设多少才不丢日志
默认 128 条在生产环境基本等于“开盒即丢”，尤其遇到定时任务、批量导入或突发流量时，关键慢命令刚写入就被覆盖。真实保留窗口取决于你单位时间产生的慢命令数量，不是拍脑袋定值。
- 先用
SLOWLOG LEN连续观察 5–10 分钟，记下峰值（比如某分钟冲到 87 条） - 再用
SLOWLOG GET 10看时间戳分布：如果 10 条全集中在同一秒内，说明洪峰密集，slowlog-max-len至少得是单峰预估量的 2–3 倍 - 中小流量业务（QPS
- 高并发/批处理场景（如凌晨 SCAN + HGETALL）：直接设 2000–3000，但必须同步监控
used_memory，避免日志吃掉 >1% 主内存
为什么不能无脑调到 10000
slowlog-max-len 每条日志存完整命令参数（已脱敏）、时间戳、耗时、ID，实际内存开销比想象中大。Redis 8.2.3 中一条典型慢日志平均占 200–400 字节，设成 10000 就可能多占 3–4MB 内存——看似不多，但在小规格实例（如 1GB 内存）里会明显挤压键值存储空间，甚至触发 maxmemory 驱逐。
- 别只看“反正内存够”，要结合
INFO memory中的used_memory_peak和mem_fragmentation_ratio综合判断 - 若发现
slowlog-max-len调高后used_memory_rss异常上涨，立刻回调 - 临时扩容（如 CONFIG SET slowlog-max-len 3000）后，记得定时脚本自动恢复原值，避免遗忘
CONFIG SET 后忘记 CONFIG REWRITE 的后果
动态设置 slowlog-max-len 或 slowlog-log-slower-than 后不执行 CONFIG REWRITE，服务重启就回滚到配置文件里的旧值——这意味着你辛苦调优的参数只生效一次，下次故障排查时发现日志又只剩 128 条，纯属白忙。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 每次
CONFIG SET后，务必跟一句CONFIG REWRITE（需有 config rewrite 权限） - 如果 Redis 启用了 ACL，确认当前用户有
config权限，否则CONFIG REWRITE会静默失败 - 检查是否写入成功：用
CONFIG GET slowlog-max-len对比 redis.conf 文件内容，二者必须一致
靠 slowlog-max-len 单独防丢失是徒劳的
slowlog 是纯内存 FIFO，不持久、不归档、不告警。哪怕你设到 5000，只要没及时捞走，它照样会在下一次洪峰里被刷掉。真正防丢失的闭环是“扩容 + 收敛 + 外卸”：
- 先用
slowlog-log-slower-than 1000（1ms）收紧阈值，把日志量压下来，让有限长度专注记录真慢命令 - 用定时任务（如每分钟
SLOWLOG GET 100）把新增日志推到外部存储（ES / S3 / 日志中心），并比对上一次 ID 避免重复 - 给
SLOWLOG LEN值配 Prometheus + Alertmanager 告警：连续 3 次 >= 90%slowlog-max-len就触发“日志即将冲刷”预警
最易被忽略的一点：slowlog 不记录网络延迟和排队时间，看到一条 5ms 的慢日志，不代表 Redis 真卡了——可能是客户端重试、代理抖动或上游超时重发。得结合 redis-cli --latency 和客户端埋点交叉验证，否则优化方向容易跑偏。
