混合持久化文件非纯AOF，前半部为RDB二进制格式（如REDIS0011魔数开头），后半部才是AOF命令；redis-check-aof等工具仅识别标准文本AOF，强行解析会破坏结构导致加载失败，真正增量命令提取应依赖monitor、ACL LOG或业务层埋点而非解析该文件。
混合持久化文件不是纯AOF，无法用AOF方式解析
因为混合持久化开启后，appendonly.aof 文件前半部分是 RDB 格式（以 REDIS0011 等魔数开头），后半部分才是 AOF 命令追加内容。工具如 redis-check-aof 或直接 cat appendonly.aof 查看时，会卡在 RDB 二进制段——它根本不是文本命令流，自然无法“单独提取增量命令”。
redis-check-aof --fix 会破坏混合结构
很多用户尝试用 AOF 修复命令清理或重写文件，但该命令只认标准 AOF 文本格式。一旦遇到开头的 RDB 数据块，就会报错或直接截断，导致：
- REDIS0011 开头被删掉
- 后续 AOF 命令失去初始快照上下文，重启时加载失败
- 实际上等同于退化为无效 AOF 文件
想看“增量部分”，得先跳过 RDB 头部再解析
混合 AOF 的 RDB 段长度不固定，但可通过以下方式定位真实 AOF 起始位置：
- 用十六进制查看器（如 xxd appendonly.aof | head -20）确认 RDB 结束位置（通常以 EOF 标记结尾）
- 找到第一个非 RDB 字节（常见是 *3\r\n$3\r\nSET\r\n 这类 AOF 协议帧）
- 从该偏移量开始用 tail -c +N appendonly.aof | redis-cli --pipe 测试是否可被管道消费（仅验证语法，不执行）
- 注意：redis-cli --pipe 本身不区分混合格式，它只按 RESP 协议逐条读取，所以必须确保跳过 RDB 部分后剩余内容是合法 AOF 帧
真正可靠的“增量命令提取”只能靠日志或监控手段
混合持久化设计目标就是让恢复更快，不是为了人工审计命令。如果你需要追踪增量变更：
- 启用 monitor 命令（仅调试，性能开销大，不可长期开）
- 使用 Redis 6.0+ 的 ACL LOG 或外部代理（如 redis-proxy）记录写请求
- 在业务层打点，所有 SET/HSET 等调用统一埋点写 Kafka
- 不要依赖解析 appendonly.aof 来做变更审计——RDB 段不可读、AOF 段无上下文、且重写过程还会动态合并
混合持久化的本质是“RDB 快照 + 增量补丁”的二合一载体，它牺牲了人类可读性来换取启动速度。想看清每条命令，就得回到纯 AOF 模式，或者换更上游的数据采集方式。
