row格式避免主从不一致，因其记录行级变更镜像而非sql语句，规避了now()等非确定性函数在从库重放时结果不同的问题。
binlog_format 设置成 ROW 为什么能避免主从不一致
因为 STATEMENT 格式下，MySQL 只记录原始 SQL，像 NOW()、UUID()、@user_var 这类非确定性函数或变量，在从库重放时会重新求值，结果可能和主库不同。ROW 格式则记录每一行变更前后的完整镜像，执行逻辑完全脱离 SQL 上下文。
实操建议：
- 生产环境主从架构必须设为
ROW，除非你明确知道所有业务 SQL 都是确定性的（几乎不存在） - 混合模式
MIXED并不“智能”——它只对少数内置函数降级为 ROW，多数自定义逻辑仍走 STATEMENT，隐患更大 - 切换前确认从库已追平，且应用无长事务；否则
ALTER INSTANCE ROTATE BINLOG后旧日志仍可能被读取到未提交的 ROW 事件
binlog_row_image=MINIMAL 会丢数据吗
不会丢数据，但会限制闪回、审计、CDC 工具的能力。它只记录被 UPDATE/DELETE 影响列的新值 + 主键/唯一键（用于定位行），不记录旧值全量镜像。
常见错误现象：
- 用
mysqlbinlog --base64-output=DECODE-ROWS -v解析时，发现### UPDATE ... BEFORE IMAGE只有主键字段，其他旧值为空 - 基于 binlog 做实时同步的工具（如 Debezium）报 “missing before image” 错误
使用场景权衡：
- 磁盘空间紧张且只需主从复制 → 用
MINIMAL - 需要闪回、审计、或者下游依赖完整前后镜像 → 改为
FULL -
NOBLOB很少用，仅当表含大 BLOB 字段且确认不需同步其内容时才考虑
sync_binlog=1 和 innodb_flush_log_at_trx_commit=1 是什么关系
两者都控制“事务提交后是否立即刷盘”，但作用对象不同：sync_binlog=1 确保 binlog 写入文件系统并落盘；innodb_flush_log_at_trx_commit=1 确保 InnoDB redo log 落盘。只有两者同时为 1，才能在崩溃后保证主从数据严格一致。
容易踩的坑：
- 只开
sync_binlog=1但innodb_flush_log_at_trx_commit=0：主库崩溃可能导致已写 binlog 的事务在 InnoDB 中丢失，从库多出数据 - 反过来只开
innodb_flush_log_at_trx_commit=1但sync_binlog=0：主库崩溃可能丢失 binlog，从库少数据 - 云数据库（如阿里云 RDS）默认关掉
sync_binlog，靠底层存储冗余兜底，自行部署必须手动打开
binlog_expire_logs_seconds 设太小会导致从库 IO 线程失败
从库的 IO 线程拉取主库 binlog 时，如果主库已自动清理掉对应文件，就会报错 Got fatal error 1236 from master when reading data from binary log，错误信息里通常带 Could not find first log file name in binary log index file 或具体缺失的 mysql-bin.000123。
实操建议：
- 先查从库延迟：
SHOW SLAVE STATUS\G看Seconds_Behind_Master，再算出安全保留时间 = 当前延迟秒数 + 缓冲（建议至少加 3600 秒） - 不要按“日”粗略设置；例如设
binlog_expire_logs_seconds=86400（1天），但某次备份卡住 2 小时，就可能触发断裂 - 监控项要加上：
SHOW BINARY LOGS查最大文件时间，对比SELECT UNIX_TIMESTAMP()-@@global.binlog_expire_logs_seconds是否已过期
最麻烦的是跨机房同步或偶尔网络抖动，binlog 清理节奏必须比最慢从节点的消费能力还保守。参数调小容易，但一旦断连，补日志往往得靠全量重建从库。
