mysql跨版本主从复制（5.7→8.0）必须显式配置binlog_format=row并验证生效，因默认值不可靠，statement格式会导致函数回放不一致；从库无需设binlog_format，但应关闭log_bin或确保log_slave_updates=off。
MySQL跨版本复制必须用ROW模式
跨版本复制（比如MySQL 5.7主库 → MySQL 8.0从库）中，binlog_format 必须显式设为 ROW，不能依赖默认值或留空。虽然MySQL 5.7+默认已是ROW，但低版本主库若未明确配置，可能仍为STATEMENT；而高版本从库在解析旧格式binlog时，对不确定函数（如NOW()、UUID()、RAND()）的回放行为可能与主库不一致，直接导致数据错位。
主库配置要锁定ROW并验证生效
仅在配置文件里写binlog_format = ROW不够，必须确认它真正在运行时生效：
- 修改
my.cnf后重启mysqld，或执行SET GLOBAL binlog_format = 'ROW';（需SUPER权限） - 立即查证：
SELECT @@binlog_format;返回值必须是ROW，不是STATEMENT或MIXED - 注意：某些云数据库（如阿里云RDS）不支持动态修改
binlog_format，必须通过控制台或参数模板变更并重启 - DDL语句（如
CREATE TABLE）始终以语句格式记录，不受binlog_format影响——这点无需干预，但要知道它存在
从库不需要改binlog_format，但得关掉非必要binlog
从库的binlog_format参数本身不影响复制过程，因为从库只读取主库binlog并重放，不靠自己的binlog_format去解析。但容易踩的坑是：如果从库也开了log_bin，又没配log_slave_updates = OFF（默认是OFF），就可能把重放操作再次写入自己的binlog——这在级联复制中才有意义，单层从库反而增加磁盘IO和潜在混乱。
所以建议：
- 从库配置中不设置
binlog_format（让它保持默认即可） - 明确关闭
log_bin，或至少确保log_slave_updates = OFF - 若未来要升级为级联节点，再打开
log_bin并设log_slave_updates = ON，此时才需同步确认其binlog_format是否匹配上游
用mysqlbinlog工具抽样检查binlog内容
光看参数值还不够，得验证实际产生的binlog事件确实是行格式。在主库上执行：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | head -n 50
如果看到类似# at 219后面紧跟着### UPDATE `test`.`t1`和### WHERE/### SET块，说明是ROW格式；若只看到原始SQL语句（如UPDATE t1 SET c=2 WHERE id=1），那就是STATEMENT格式，必须立刻修正。
这个检查动作常被跳过，但它能暴露配置是否真正落地、以及是否有中间件（如ProxySQL）或应用层强制切换了会话级binlog_format。
