MySQL 5.7已有实例的binlog_format默认未必是ROW，需通过SHOW VARIABLES LIKE 'binlog_format'确认，若非ROW则必须在my.cnf中以binlog-format=ROW（短横线）显式配置并重启生效，且需同步设置binlog_row_image=FULL确保字段镜像完整。
确认当前binlog_format是否已是ROW
很多用户以为改了配置就生效，结果SHOW VARIABLES LIKE 'binlog_format'返回的仍是STATEMENT。这是因为MySQL 5.7虽默认用ROW，但仅限全新初始化实例；已有实例若未显式配置，可能沿用旧值或被启动参数覆盖。
执行以下命令验证：
SHOW VARIABLES LIKE 'binlog_format';
若返回VALUE为STATEMENT或MIXED，必须手动干预。注意：该变量是只读的，无法用SET GLOBAL动态修改，只能靠配置文件重启生效。
在my.cnf中正确设置binlog-format=ROW
配置项名是binlog-format（带短横线），不是binlog_format（下划线）——写错会导致MySQL启动时忽略该行，且不报错。
编辑/etc/my.cnf（Linux）或my.ini（Windows），在[mysqld]段落内添加：
[mysqld] log-bin = /var/lib/mysql/binlog/mysql-bin server-id = 1 binlog-format = ROW
-
log-bin路径必须指向一个**已存在且MySQL进程有写权限的目录**，否则mysqld启动失败，错误日志里会出现Can't open the log file -
server-id必须是非零整数，即使单机也别设为0；主从环境中各节点必须唯一 - 不要加引号，例如
binlog-format = "ROW"会触发解析失败
补充关键参数：binlog_row_image=FULL
仅设binlog-format = ROW还不够。MySQL 5.7引入binlog_row_image控制ROW模式下记录哪些字段镜像，默认值是FULL，但部分老部署可能被误设为MINIMAL——这会导致UPDATE/DELETE事件缺失WHERE条件所需字段，闪回或审计时查不到原始值。
检查并确保：
SHOW VARIABLES LIKE 'binlog_row_image';
若返回MINIMAL，需在[mysqld]中追加：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
binlog_row_image = FULL
这个参数可动态修改，但建议仍写入配置文件，避免重启后丢失：
SET GLOBAL binlog_row_image = 'FULL';
重启后验证binlog写入是否真实生效
重启MySQL后，不能只看log_bin=ON和binlog_format=ROW就认为万事大吉。要确认实际写入的是ROW事件，最直接的方式是触发一次变更并解析日志：
执行一条UPDATE：
USE test; CREATE TABLE t1(id INT PRIMARY KEY, v VARCHAR(10)); INSERT INTO t1 VALUES(1, 'a'); UPDATE t1 SET v='b' WHERE id=1;
然后用mysqlbinlog解析最新binlog文件（路径见SHOW VARIABLES LIKE 'log_bin_basename'）：
mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS /var/lib/mysql/binlog/mysql-bin.000001 | grep -A5 -B5 "UPDATE\|WHERE"
如果输出中出现### WHERE和### SET块，且包含@1=1、@2='a'等字段镜像，则说明ROW格式真正起效。若只有UPDATE ... SET ... WHERE ...一行SQL文本，那还是STATEMENT模式在偷偷工作。
容易被忽略的一点：某些云数据库托管服务（如阿里云RDS、腾讯云CDB）禁用log-bin配置权限，即使你改了配置文件，重启后也会被自动还原——这种场景必须走控制台开关或工单申请。
