Redis的AOF仅在SELECT导致数据库切换且后续有写命令时记录该SELECT；重写时按key所属db归类命令，可能增删SELECT；混合持久化下多db不安全。
SELECT 指令在 AOF 文件里到底记不记录
记，但只在特定条件下。Redis 的 AOF 日志默认不会为每个 SELECT 命令单独写一条日志，除非它触发了数据库上下文切换——也就是前一条命令操作的 db 编号和当前 SELECT 指定的 db 不同，且后续有写命令。
常见错误现象是：AOF 文件里搜不到 SELECT 1，误以为它被忽略；实际是 Redis 做了合并优化——只有“真正影响后续写入目标库”的 SELECT 才落盘。
- 如果连续执行
SELECT 1、SET a b，AOF 中会先写SELECT 1，再写SET a b - 如果执行
SELECT 1、SELECT 1、SET a b，AOF 中只有SET a b（第二次SELECT 1被跳过） - 如果执行
SELECT 0、SELECT 1、SET a b，AOF 中会出现SELECT 1和SET a b，因为发生了跨库切换
AOF 重写时 SELECT 怎么处理
重写过程不保留原始 SELECT 流，而是按最终每个 key 所属的 db，把写命令归类到对应 SELECT N 后面。这意味着重写后的 AOF 可能比原日志多出若干 SELECT，也可能更少——取决于 key 分布和历史切换频次。
性能影响在于：重写需遍历所有 key，查其所属 db，再排序组织命令；db 数越多（比如用了 10 个 db），重写时内存开销略增，但通常可忽略。
- 重写不会保留中间无用的
SELECT，比如SELECT 0 → SET x 1 → SELECT 1 → SET y 2重写后变成SELECT 0SET x 1SELECT 1SET y 2 - 如果某个 db 完全没 key，重写后该 db 对应的
SELECT不会出现 - 配置项
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size不影响SELECT的生成逻辑，只控制重写时机
多数据库 + AOF + RDB 混用时容易踩的坑
Redis 不支持 AOF 和 RDB 混合持久化时保留多 db 上下文一致性。如果你开了 aof-use-rdb-preamble yes，RDB 部分只保存当前 db（通常是 db 0）的快照，而 AOF 部分仍按各 db 分离记录——恢复时，RDB 加载完再执行 AOF，可能导致非 db 0 的 key 被覆盖或丢失。
使用场景上，纯 AOF 模式下多 db 是安全的；但只要启用了 RDB 或混合模式，就等于主动放弃 db 1~15 的原子性保障。
- 错误现象：
redis-cli -n 1 SET foo bar写入后，重启发现foo不存在——大概率是混合持久化 + RDB 先加载覆盖了 db 1 状态 - 兼容性注意：Redis 7.0+ 对多 db 支持未变，但官方文档已明确建议“尽量只用 db 0”，AOF 中的
SELECT逻辑也未调整 - 调试方法：用
redis-check-aof --fix查看 AOF 实际内容，比直接cat更可靠，避免二进制混淆
如何验证某条 SELECT 是否进了 AOF
最直接的办法是清空 AOF、执行最小复现步骤、然后检查文件末尾。别依赖 redis-cli monitor，它不反映落盘行为；也别只看 INFO 输出，aof_current_size 变化太粗粒度。
关键点在于：必须有后续写命令，否则 SELECT 不会写入。这是最容易被忽略的设计细节。
- 正确验证步骤：
redis-cli CONFIG SET appendonly no→redis-cli CONFIG SET appendonly yes（清空并重建 AOF）→redis-cli -n 0 SET x 1→redis-cli -n 1 SET y 2→tail -n 5 appendonly.aof - 你会看到
SELECT 1和SET y 2成对出现，但没有SELECT 0（因为初始状态就是 db 0） - 如果只执行
redis-cli SELECT 1不跟写命令，AOF 文件大小不变，SELECT 1不会出现
SELECT 的记录不是“指令级镜像”，而是“写命令驱动的上下文快照”。想靠它还原完整交互流，会漏掉大量无后续写入的 SELECT；想靠它做多 db 数据迁移，得额外处理 db 映射逻辑。 
