flushall误执行后数据可恢复但需人工干预：立即shutdown nosave停服，精准删除aof中含select和flushall的完整resp协议块，用redis-check-aof验证修复，清空rdb并确保无残留进程后重启。
FLUSHALL 误执行后，只要 AOF 文件未被重写、且 appendonly yes 开启，数据大概率可恢复——但不是“自动还原”，而是靠人工精准剥离日志中那条破坏性命令，并确保其余写入指令完整有效。
必须立刻停服：shutdown nosave 是唯一安全起点
Redis 运行时会持续追加命令到 appendonly.aof，且可能随时触发 bgrewriteaof。一旦重写发生，旧 AOF 被覆盖，所有 SET/HSET 等原始写入记录就永久丢失。
- 执行
redis-cli shutdown nosave：关键在nosave，它阻止 Redis 关机前 dump 内存或追加新日志，避免污染 AOF - 紧接着确认进程已退出：
ps aux | grep redis或systemctl is-active redis - 不要依赖
kill -9后直接编辑文件——若进程残留，文件可能被锁或仍在写入
识别并删除 FLUSHALL 的完整 RESP 协议块，不是单搜字符串
AOF 是 RESP 文本协议，FLUSHALL 不是孤立一行，而是一个多行结构，常见形式包括：
- 简单版：
*1\r\n$8\r\nFLUSHALL\r\n - 带 DB 切换版：
<em>2\r\n$6\r\nSELECT\r\n$1\r\n0\r\n</em>1\r\n$8\r\nFLUSHALL\r\n
直接用 grep "FLUSHALL" appendonly.aof 极易误匹配（比如 key 名含该字符串），也漏掉前面的 SELECT 行。
- 用
tail -n 200 appendonly.aof | hexdump -C查看末尾二进制，确认$8\r\nFLUSHALL\r\n的真实边界（注意\r\n是两个字节） - 在副本文件中反向查找（vim 中
?^*1$或?SELECT），定位整个区块，只删从SELECT（如有）到FLUSHALL结束的全部行 - 删完检查前后是否仍有合法命令，如上一条是
<em>3\r\n$3\r\nSET\r\n...</em>，下一条是3\r\n$3\r\nSET\r\n...，中间不能断层
改完必须用 redis-check-aof 验证，否则启动必报错
手动编辑极易引入格式错误：少一个 \r\n、长度数字标错（如把 $8 写成 $7）、多空格等，都会导致 Redis 启动失败，报错类似：
Bad file format reading the append only fileWrong RDB checksum（混合持久化下也可能触发）运行
redis-check-aof --fix appendonly.aof.backup，务必在副本上操作，原文件只读--fix仅修复基础换行与长度校验，不判断业务逻辑；它可能剔除末尾不完整命令，但不会帮你“选哪条 DEL 该留”若验证失败，说明删多了或格式错，退回上一版重新定位
重启前清空内存与 RDB，防止数据叠加冲突
即使 AOF 恢复成功，若 Redis 启动时加载 AOF 前内存里已有残留（比如上次没清干净），或配置了 save 导致 dump.rdb 被加载，就会出现：
同名 key 重复写入，过期时间错乱
EXPIRE时间被覆盖，导致数据提前失效确保
redis.conf中dbfilename和dir指向正确路径删除当前目录下的
dump.rdb（如有）启动前再次确认无残留
redis-server进程，再执行redis-server redis.conf
真正容易被忽略的，是“FLUSHALL”往往不是孤零零一行，而是一组协议单元；删得不全，残留的 SELECT 会让后续所有 SET 写进错误 DB，数据看似回来，实则错位。
