必须用row模式，因其记录行级变更快照而非sql语句，可彻底规避now()、uuid()、用户变量等非确定性因素导致的主从永久性数据错位；需主从均显式配置binlog-format=row并重启生效，且须验证实际binlog事件为where/set格式而非纯sql。
为什么必须用ROW模式而不是STATEMENT
因为STATEMENT格式只记录原始SQL语句，而MySQL在从库重放时可能因函数、时间、用户变量、自增行为等非确定性因素导致结果不一致。比如NOW()、UUID()、INSERT ... SELECT带ORDER BY RAND()，主库执行一次生成固定结果，从库重放时却可能生成不同数据。这种分歧不是延迟问题，而是永久性数据错位，且极难发现。
binlog-format=ROW的配置要点和常见遗漏
必须在主库和从库都显式设置，不能只设主库。否则从库可能以STATEMENT或MIXED解析relay log，照样出错。配置项要写在[mysqld]段下，并重启生效（MySQL 8.0.23+支持动态修改，但建议仍重启验证）：
binlog-format=ROW
还要确认以下配套参数已启用：
-
log-bin必须开启（主库） -
server-id在主从节点间必须唯一（哪怕只有一主一从） - 从库建议加
read_only=1防止误写（但不影响复制线程）
ROW模式下仍可能出问题的几个真实场景
ROW本身不解决所有一致性问题，以下情况仍需人工干预：
- 主库执行了
DROP TABLE或TRUNCATE TABLE后，从库对应表被应用层改名或删掉，SQL线程会报Table doesn't exist错误并停止复制 - 主库用了
ALTER TABLE ... ALGORITHM=INPLACE但从库MySQL版本不支持该算法，导致SQL Thread卡住 - 从库开启了
sql_log_bin=0后手动写入数据，后续主库相同主键行更新，会触发Duplicate entry或Row not found错误 - 主库有
ENUM或SET字段，但定义顺序在主从之间不一致（比如建表语句拷贝时字段顺序错乱），ROW event解析时值映射错位
如何验证当前复制确实在用ROW模式运行
别只信配置文件。登录主库执行：
SHOW VARIABLES LIKE 'binlog_format';
再查一条最近的binlog事件内容：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | head -20
如果看到类似### UPDATE `test`.`t1`后面跟着### WHERE和### SET块，说明是ROW格式；若只有UPDATE t1 SET ...一行SQL，则仍是STATEMENT。
真正容易被忽略的是：即使主库设了ROW，如果从库的relay_log_info_repository是FILE且未配relay_log_recovery=ON，主库异常重启后从库可能从错误位置重放——这时ROW也救不了你。
