Redis AOF自动重写不触发的主因是aof_base_size为0或未更新、增长未达auto-aof-rewrite-percentage阈值、磁盘空间不足致重写失败后基准值冻结；手动重写需用BGREWRITEAOF命令。
Redis AOF重写不触发？先确认auto-aof-rewrite-percentage是否生效
这个配置项本身不会“强制触发”，它只是开启自动重写的条件开关。真正触发的前提是：AOF文件当前大小比上次重写后大小增长了指定百分比，且当前AOF文件大小超过auto-aof-rewrite-min-size（默认64MB）。如果AOF刚启动或上一次重写失败，Redis会跳过判断直接拒绝触发。
- 检查
CONFIG GET auto-aof-rewrite-percentage和CONFIG GET auto-aof-rewrite-min-size，确认值不是0或负数 - 用
INFO persistence看aof_current_size和aof_base_size——如果aof_base_size为0，说明还没成功完成过重写，自动机制不会启动 - 若
aof_base_size存在但差值未达阈值，auto-aof-rewrite-percentage再大也没用
想立刻重写AOF？用BGREWRITEAOF命令，不是改配置
配置项只影响“自动”行为；手动强制重写必须发命令。它会fork子进程生成新AOF，不影响主进程处理请求，但会消耗额外内存和CPU。
-
BGREWRITEAOF返回Background append only file rewriting started表示已提交任务，不是立即完成 - 执行中可用
INFO persistence观察aof_rewrite_in_progress是否为1，以及aof_rewrite_scheduled是否为0（为1说明有延迟调度，通常因no-appendfsync-on-rewrite为yes且有fsync在跑） - 如果返回
ERR Background append only file rewriting already in progress，说明已有重写在跑，Redis不允许并发重写
auto-aof-rewrite-percentage设太高或太低都容易出问题
设为0就彻底禁用自动重写；设为100意思是增长100%才触发，但若业务写入少，可能几个月都不触发，AOF越积越大。反过来，设成10会导致频繁重写，尤其小文件场景下IO压力明显。
- 生产环境建议：写入量稳定时设50~100，写入突增明显时可临时调低到20~30，但需配合监控
aof_rewrite_duration_sec - 注意
no-appendfsync-on-rewrite默认为yes——重写期间主线程不执行fsync，若此时宕机，AOF可能丢失重写开始后的部分数据 - 重写过程本身不阻塞写命令，但子进程会copy-on-write内存页，若实例内存碎片高或使用大量bigkey，fork可能卡顿甚至失败（日志报
Can't fork for AOF rewrite）
重写失败后aof_base_size不会更新，下次自动判断永远失效
这是最容易被忽略的点：只要一次BGREWRITEAOF失败（比如磁盘满、权限不足、子进程OOM），Redis就不会更新aof_base_size，导致后续所有自动判断都基于一个过期的基准值，永远达不到增长百分比。
- 查日志关键词：
AOF rewrite failed、Could not rename、No space left on device - 失败后必须人工介入：清空磁盘、修复权限，然后手动跑一次成功的
BGREWRITEAOF，才能让aof_base_size刷新 - 别依赖
CONFIG SET动态修改aof_base_size——这个值只读，无法通过配置命令覆盖
aof_base_size冻结、fork失败、或磁盘空间这类底层事实。 
