MySQL主从复制推荐使用ROW格式：它保障主从数据严格一致、支持并行复制与审计回滚，虽日志体积大但现代业务强一致性场景必备；STATEMENT节省空间却易因非确定函数导致不一致；MIXED为折中但逐渐被弱化。
MySQL主从复制中，ROW 和 STATEMENT 是两种核心的二进制日志（binlog）格式，直接影响数据一致性、性能和可维护性。选错格式可能导致主从数据不一致、复制中断或无法审计变更。
STATEMENT 模式：记录的是 SQL 语句本身
主库把执行的原始 SQL（如 UPDATE users SET status=1 WHERE id=5）写入 binlog，从库重放这条语句完成同步。
- 日志体积小，尤其对批量更新操作更节省磁盘和网络开销
- 依赖语句的确定性：如果语句含
NOW()、UUID()、USER()、自增主键插入后又用LAST_INSERT_ID()等非确定性函数，从库执行结果可能与主库不同 - 某些语句在从库执行时因环境差异（如表结构、索引、SQL_MODE）失败，导致复制中断
- 难以精准追踪某一行数据是如何被修改的，不利于数据审计或回滚分析
ROW 模式：记录的是行数据变更前后的快照
主库不记录 SQL，而是记录每行数据变化的详细信息。例如某条 UPDATE 实际影响了哪几行、旧值是什么、新值是什么，都以二进制形式写入 binlog。
- 复制安全性高：不受函数不确定性、执行环境差异影响，主从数据严格一致
- 支持并行复制（如基于 schema 或 table 的 worker 分发），提升从库同步效率
- 便于数据恢复、审计、增量同步工具（如 Canal、Maxwell）解析；也方便做行级闪回或误操作回滚
- 日志体积大，尤其对全表更新、大字段修改或高并发更新场景，会显著增加磁盘 IO、网络带宽和从库解析压力
MIXED 模式：STATEMENT 和 ROW 的折中方案
MySQL 默认采用 MIXED 模式，由系统自动判断：对确定性语句用 STATEMENT，对可能引发不一致的操作（如含非确定函数、临时表、存储过程等）自动切换为 ROW。
- 兼顾兼容性与安全性，适合历史系统平滑过渡
- 但自动切换逻辑较复杂，排查问题时需额外确认当前语句实际使用的格式
- 部分高版本 MySQL（如 8.0.26+）已逐步弱化 MIXED 支持，推荐明确指定 ROW
怎么选？看场景，不是看版本
现代业务系统强烈建议直接使用 ROW 模式：
- 金融、电商、支付等强一致性要求场景必须用 ROW
- 使用 GTID 复制时，ROW 更稳定，STATEMENT 在某些 GTID 场景下有兼容性限制
- 若已有大量非确定性 SQL，且无法改造，才考虑 STATEMENT + 严格 SQL_MODE + 定期校验
- 混合部署（如读写分离+分库分表中间件）下，ROW 是主流中间件（ShardingSphere、MyCat）的首选解析格式
不复杂但容易忽略：改 binlog_format 后，必须重启从库的 IO 线程（STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;）才能生效，仅重启 SQL_THREAD 不够。
