CONFIG SET appendonly no 的真实行为是停止追加新命令、触发最终AOF rewrite生成最小化快照文件、清空缓冲区，但不删除原AOF文件且不修改配置项。
不能直接关闭正在写入的 AOF 文件，CONFIG SET appendonly no 会触发 Redis 自动重写并清空当前 AOF 缓冲区，但旧 AOF 文件仍保留在磁盘上——这不是“关闭”，只是停写新内容。
CONFIG SET appendonly no 真实行为是什么
这条命令不是“关掉 AOF”，而是让 Redis 停止追加新命令到 appendfilename 指定的文件，并在后台完成一次最终的 AOF rewrite（如果缓冲区非空），生成一个最小化快照式 AOF 文件，然后清空缓冲区。原 AOF 文件不会被删除，也不会被自动禁用加载。
- 执行后
redis.conf中的appendonly仍是yes，重启后仍会加载原 AOF 文件 - Redis 进程里
INFO persistence显示aof_enabled:0，但aof_current_size和aof_base_size不归零 - 若此时手动删掉
appendfilename对应的文件，重启会报错：Failed opening the AOF file: No such file or directory
想真正停用 AOF，必须做三件事
仅靠 CONFIG SET 不足以让 AOF “消失”。要让 Redis 彻底不依赖 AOF 启动，需同步操作配置、文件和持久化策略：
- 先执行
CONFIG SET appendonly no停止追加 - 再执行
CONFIG SET appendfilename ""（可选，但避免后续误加载） - 手动删掉磁盘上的 AOF 文件（路径见
CONFIG GET appendfilename），否则重启时仍会尝试加载 - 修改
redis.conf：把appendonly yes改成appendonly no，否则下次重启又启用
为什么不能只删文件不改配置
Redis 启动时按 redis.conf 的 appendonly 和 appendfilename 决定是否加载 AOF。即使你删了文件，只要 appendonly yes 且 appendfilename 指向某个路径，Redis 就会在启动时检查该路径是否存在；不存在就报错退出，不会自动 fallback 到 RDB。
- 典型错误现象：
Can't handle RDB format reading from AOF file或直接Failed opening the AOF file - 常见场景：运维同学删了
appendonly.aof，但忘了改 conf，重启服务失败 - 兼容性影响：Redis 6.0+ 对缺失 AOF 文件更严格，老版本可能静默创建空文件，但行为不可靠
如果只是临时停写，别删文件
某些场景下（比如压测期间想排除 AOF IO 干扰），你只需要暂停写入，而不是彻底弃用 AOF。这时只需 CONFIG SET appendonly no，保留文件，之后再 CONFIG SET appendonly yes 即可恢复——Redis 会从上次 rewrite 的位置继续追加。
- 注意：恢复前确保
appendfilename指向的是原文件，别被中间改过名或路径 - 性能影响：AOF rewrite 本身有 CPU 和 I/O 开销，频繁开关会引发多次 rewrite，不建议高频切换
- 容易踩的坑：
CONFIG SET appendonly yes后没立刻生效？检查INFO persistence的aof_rewrite_in_progress是否为 1，rewrite 完才真正开始追加
最常被忽略的一点：AOF 文件是否被其他进程（比如备份脚本、监控工具）正在读取或锁定。直接 rm 可能失败，或者导致 Redis 在 rewrite 时写入异常——动手前先 lsof -p $(pgrep redis) 看看有没有对 AOF 文件的句柄残留。
