只改binlog_format='row'不够，因旧连接仍写statement日志导致混合日志，且未同步调整binlog_row_image=full、sync_binlog=1、innodb_flush_log_at_trx_commit=1三项关键参数，无法保障数据一致性和日志可靠性。
为什么只改 binlog_format = 'ROW' 不够？
直接在 my.cnf 里写 binlog_format=ROW 并重启，只是完成了“格式切换”的一半。真正出问题的不是配置本身，而是旧日志残留、会话级变量干扰、以及配套参数没对齐。常见现象是：主库 SHOW VARIABLES 显示 ROW，但从库同步时仍报 Error_code: 1032 或 ha_err_key_not_found——这说明从库在解析 UPDATE_ROWS 事件时找不到对应行，根源是主从数据不一致，而 ROW 模式会把这个问题立刻暴露出来，不是它引发的，而是它“照出了”已存在的裂痕。
必须同步调整的三个关键参数
单独设 binlog_format=ROW 是危险的起点。以下三项必须一起配，缺一不可：
-
binlog_row_image=FULL：默认值，但务必显式声明。若为MINIMAL，从库无法还原完整前镜像，pt-table-checksum校验失效，误删恢复也无依据 -
sync_binlog=1：确保每次事务提交都刷盘，避免主库 crash 后 binlog 缺失部分事件，导致从库后续解析断层 -
innodb_flush_log_at_trx_commit=1：与sync_binlog=1配套，保证 InnoDB redolog 和 binlog 事务一致性，防止半提交状态被复制
注意：binlog_row_image 是全局动态变量，可在线改（SET GLOBAL binlog_row_image = 'FULL'），但必须在 binlog_format 切换前完成，否则新写入的日志可能仍按旧 row_image 规则生成。
切换时最容易踩的坑：会话级残留 + 混合日志
binlog_format 是会话级变量，SET GLOBAL 只影响新连接。老连接（比如长连接应用、监控采集脚本）仍按原格式写日志，造成同一个 binlog 文件里混着 STATEMENT 和 ROW 事件——从库解析时可能突然卡在某个 UPDATE_ROWS 上，因为前面的 STATEMENT 事件已让数据状态偏移。
- 切之前用
SHOW PROCESSLIST查是否有活跃写连接，必要时 kill 或等其自然断开 - 切完后执行
FLUSH BINARY LOGS，强制滚动新文件，确保后续日志干净 - 不要依赖
SET GLOBAL binlog_format = 'ROW'就完事，必须改配置文件并重启 mysqld，否则重启后回退
验证是否真生效：别只看变量，要看日志内容
运行 SHOW VARIABLES LIKE 'binlog_format' 返回 ROW 不代表万事大吉。要确认实际写入的 binlog 是否真是 ROW 格式：
- 用
mysqlbinlog --base64-output=DECODE-ROWS -v /var/lib/mysql/mysql-bin.000001解析最新 binlog - 看到类似
### UPDATE `test`.`t` ### WHERE ### @1=1 /* LONGINT meta=0 nullable=0 is_null=0 */这样的结构，才是真正的 ROW 事件 - 如果看到
# INSERT INTO t VALUES (1, NOW())这类原始 SQL，则仍是 STATEMENT 或 MIXED fallback
真正麻烦的是：切换后没立刻验证，等一周后发现主从不一致，再查 binlog，发现前两天的日志还是 STATEMENT 格式——因为那些连接一直没断，日志已过期被 purge，无法追溯。
