必须用ROW模式当业务要求主从100%一致时，如金融账务、订单状态、实时风控等场景，因其记录行级变更而非SQL语句，可彻底规避NOW()、UUID()等非确定性函数导致的主从不一致问题。
什么时候必须用 ROW 模式
如果你的业务要求主从数据 100% 一致，比如金融账务、订单状态变更、实时风控决策依赖从库查询，那就别犹豫，直接设为 ROW。它不靠重放 SQL，而是记录「哪一行、哪个字段、从什么值变成什么值」，彻底绕开 NOW()、RAND()、UUID()、触发器、存储过程这些在 STATEMENT 下会翻车的点。
常见错误现象：INSERT INTO log VALUES (UUID(), NOW()) 在主库插入了一条带时间戳和唯一 ID 的日志，从库回放时生成了另一个 UUID() 和另一秒的 NOW()，导致主从行内容完全不一致——这种问题在 ROW 下根本不会发生。
实操建议：
- MySQL 5.7+ 默认已是 ROW，但别信默认，查一下：SELECT @@binlog_format;
- 修改需重启复制或至少 stop/start slave（取决于是否启用了 binlog_transaction_dependency_tracking）
- 注意：DDL 如 ALTER TABLE 在 ROW 下会触发全表扫描并逐行写 binlog，大表操作前务必评估磁盘 IO 和网络带宽
MIXED 真正适用的场景是什么
MIXED 不是“折中”，而是“有条件的自动降级”：默认走 STATEMENT，一旦检测到非确定性操作（如含 UUID() 的 INSERT、调用自定义函数、SYSDATE()），就临时切到 ROW 记录那条语句。它适合大多数 Web 应用——有少量动态函数，但主体是简单 CRUD。
但容易踩的坑是：你以为它“智能”，其实它的判断边界很窄。比如你写了 INSERT ... SELECT FROM (SELECT RAND() * 100)，MySQL 可能仍按 STATEMENT 记录，因为子查询没被识别为非确定性上下文；又或者你用了一个 UDF，但函数体里没显式声明 DETERMINISTIC，MySQL 就不敢保证，直接切 ROW，结果某天批量导入突然把 binlog 打爆。
实操建议：
- 查看实际生效模式：SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 10;，观察事件类型是 Query_log_event（statement）还是 Write_rows_log_event（row）
- 不要依赖 MIXED 来掩盖代码里的不确定性，优先改业务逻辑（比如把 UUID() 移到应用层生成）
- 如果已上线系统长期跑 MIXED 且无异常，说明当前 SQL 覆盖面较干净，可暂不升级；但新项目建议直接上 ROW，省去排查“为什么这条语句没同步”的时间
STATEMENT 还有没有存在的必要
有，但非常窄：仅限于离线数仓同步、报表库只读从库、或极老系统无法升级且确认无任何非确定性 SQL。它的优势只剩两个：binlog 文件小、主库写入压力低。但代价是随时可能主从不一致，且修复困难——你没法从 binlog 里看出某条 UPDATE 实际影响了几行，只能靠人工比对。
性能影响明显：一条 UPDATE user SET status=1 WHERE create_time 在 <code>STATEMENT 下只记一条日志；若该条件命中 50 万行，在 ROW 下就是 50 万条变更事件，可能卡住 dump 线程、拖慢主库 fsync。
实操建议：
- 禁止在生产 OLTP 主库使用 STATEMENT
- 若从库用于备份恢复，STATEMENT 的 binlog 无法做精确时间点恢复（PITR），因为无法定位到某毫秒内哪几行变了
- STATEMENT 模式下，CREATE TEMPORARY TABLE 类语句无法被正确复制，从库会报错 ERROR 1146 (42S02): Table doesn't exist
切换格式前必做的三件事
很多人改完 binlog_format 就以为完事了，结果第二天发现从库延迟飙升或复制中断。真实风险藏在细节里。
实操建议：
- 检查所有正在运行的长事务：SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW()) - TIME_TO_SEC(TRX_STARTED) > 60;，未提交事务在格式切换后可能无法正常写入 binlog
- 确认从库 relay log 已全部执行完毕：SHOW SLAVE STATUS\G 中 Relay_Master_Log_File 和 Exec_Master_Log_Pos 应与主库 SHOW MASTER STATUS 一致
- 测试 DDL 行为：在测试环境执行一次 ALTER TABLE t ADD COLUMN c2 INT，观察 binlog 事件类型和大小变化，避免上线后因 DDL 触发巨量 row event 导致磁盘写满
真正难的不是选哪个格式，而是搞清你的 SQL 到底“确不确定”——很多看似静态的语句，一加上 CONNECTION_ID()、USER() 或隐式类型转换，就悄悄越界了。别靠猜，用 mysqlbinlog --base64-output=decode-rows -v 多看几条真实日志。
