row格式是主从复制的默认推荐，因其记录具体行变更而非sql语句，避免了now()、uuid()等非确定性操作导致的主从不一致；需配置binlog-format=row并验证生效，同时关注binlog体积与性能平衡。
为什么ROW格式是主从复制的默认推荐
因为STATEMENT模式在非确定性操作下极易导致主从数据不一致，比如NOW()、UUID()、INSERT ... SELECT带自增列、触发器或存储函数里含随机/时间相关逻辑时，从库重放SQL可能产生不同结果。而ROW格式记录的是“哪一行被改成了什么样”，不依赖上下文执行环境，一致性有保障。
实操建议：binlog-format=ROW应作为新部署的强制起点；除非你明确知道所有业务SQL都是确定性的，且已做过充分验证，否则不要碰STATEMENT。
MIXED模式不是“自动兜底”，它有隐式切换风险
MIXED模式下，MySQL会根据语句类型自动选择STATEMENT或ROW记录——但这个判断逻辑不透明，且某些语句（如含LOAD DATA INFILE、部分DDL）可能意外触发ROW，而另一些看似安全的语句又可能被误判为STATEMENT。线上环境一旦出现主从不一致，很难回溯是哪条语句、在哪次自动切换时埋的坑。
常见错误现象：SHOW SLAVE STATUS里Seconds_Behind_Master忽高忽低，或Slave_SQL_Running_State频繁卡在“Reading event from the relay log”，背后常是MIXED下某条语句在从库解析失败。
使用场景：仅适用于遗留系统迁移过渡期，且必须配合binlog_row_image=FULL和严格审计日志；生产环境不建议长期启用。
配置后必须验证binlog-format是否真正生效
改完my.cnf重启MySQL只是第一步，很多用户忽略了确认环节。即使配置写对了，也可能因权限不足、配置段落错位（比如写在[client]而非[mysqld]）、或被启动脚本覆盖而失效。
验证方法：登录MySQL执行SHOW VARIABLES LIKE 'binlog_format';，返回值必须是ROW（大小写敏感）；再用mysqlbinlog工具抽样解析一个binlog文件，确认事件类型为Write_rows_v2或Update_rows_v2，而非Query事件。
容易踩的坑：binlog_format是动态变量，但**仅对新连接生效**；已有连接仍按旧格式记录，所以重启服务 + 重启客户端连接（或等连接池轮换）才完整生效。
ROW模式下要注意binlog体积和磁盘压力
ROW格式会记录整行变更前后的镜像（尤其binlog_row_image=FULL时），对大字段（TEXT、BLOB）或批量更新操作，binlog体积可能比STATEMENT大数倍，进而影响网络传输、磁盘IO和清理策略。
参数差异：binlog_row_image可设为FULL（默认）、MINIMAL（只记变更列+主键）或NOBLOB（排除BLOB类字段）。若业务能保证主键/唯一键稳定，MINIMAL可显著减小日志量，但要求从库表结构与主库严格一致（否则SQL线程找不到行）。
性能影响：高并发UPDATE场景下，ROW + sync_binlog=1 + innodb_flush_log_at_trx_commit=1组合会明显拖慢TPS；这时需权衡一致性与吞吐，不能只盯着binlog-format单点调优。
ROW不是为了“更高级”，而是规避不可控的不一致；但一旦选了，就得配套管好中继日志路径、expire_logs_days、磁盘空间监控——否则某天relay-log写满或binlog轮转失败，复制就静默停摆了。
