config set可热更新持久化参数但不清理历史状态、不补写旧数据、不保证文件立即生成；如config set appendonly yes后aof未出现，是因首次启用需bgrewriteaof成功，失败则文件为空，须查aof_rewrite_in_progress和aof_last_bgrewrite_status。
能，但必须用 CONFIG SET，且多数参数改完只是“运行时生效”，不清理历史状态、不补写旧数据、也不保证磁盘文件立刻生成。
CONFIG SET appendonly yes 为什么 AOF 文件没出现
执行 CONFIG SET appendonly yes 返回 OK 不代表 AOF 就开始写了——它只开启后续写操作的记录，但首次启用会触发一次 BGREWRITEAOF 后台重写，这个过程可能静默失败。
- 必须检查
INFO persistence中的aof_rewrite_in_progress和aof_last_bgrewrite_status，不能只看aof_enabled - 如果 Redis 启动时没配
appendonly yes，也没找到appendfilename对应的文件，首次开启就依赖这次重写成功；失败则 AOF 文件为空、无写入 - 旧版本（如 3.2 之前）需先
CONFIG SET aof-enabled yes，再CONFIG SET appendonly yes，否则无效 - 已启用过又关掉的实例，再开不会补写历史命令，只从那一刻起记新操作
CONFIG SET save "60 10000" 后 bgsave 就不自动触发
save 规则是“滑动窗口 + 累计计数”，不是定时器，改完后不会回溯触发，也不会重置 dirty 计数器。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 上一次
bgsave刚完成，那下次至少要等满 60 秒且累计新增 10000 次修改才可能满足条件 - 触发前提还包括：
rdb_bgsave_in_progress == 0、无AOF rewrite正在进行、内存足够 fork 子进程 - 验证是否生效：用
DEBUG SLEEP 0.1+INCR testkey循环几十次，再查INFO persistence中的rdb_changes_since_last_save是否递增 - 设成空字符串
CONFIG SET save ""可禁用自动快照，但SAVE/BGSAVE手动命令仍可用
CONFIG SET appendfsync everysec 切换后数据就可能丢
appendfsync 热更新是即时、不可逆、无缓冲期的——切到 everysec 的那一瞬间，上一条 always 模式下已刷盘的命令和下一条还在 buffer 里的命令之间，存在最多 1 秒断电即丢的窗口。
- 切换不校验磁盘 I/O 状态，也不等待当前日志刷盘完成
- 从
always→everysec或no都有风险，且无法回滚 - 生产环境慎用
appendfsync no，即使热更新成功，也意味着 AOF 日志完全依赖操作系统缓存，崩溃可能丢失大量数据 - 所有
CONFIG SET修改都不持久化，Redis 重启后恢复原始配置，必须同步改redis.conf
真正容易被忽略的是：热更新只改行为，不清理残留状态。比如关 AOF 时只设 aof-enabled no 而漏掉 appendonly no，AOF 文件仍保持打开并持续增长；又比如切 appendfsync 前没确认当前 buffer 是否清空，切换瞬间就埋下丢失隐患。
