必须修改配置文件并重启mysqld才能使binlog_format=row真正生效；set global仅临时覆盖，重启即失效；验证须用select @@global.binlog_format，而非show variables；配置须置于[mysqld]段且格式正确；重启后需通过mysqlbinlog确认事件格式为row。
必须改配置文件 + 重启 mysqld 才算真正生效，SET GLOBAL binlog_format = ROW 只是临时会话级覆盖，重启后就丢。
确认当前 binlog_format 值是否已是 ROW
别只信 SHOW VARIABLES LIKE 'binlog_format' 的返回结果——它可能显示 ROW，但实际生效的是 session 级旧值。务必查全局值：
-
SELECT @@global.binlog_format;是唯一可信指标；@@session.binlog_format可能被连接初始化脚本或 ORM 自动覆盖 - 如果返回
STATEMENT或MIXED，说明配置未落地，下一步必须改配置文件 - 注意：MySQL 8.0.33+ 在某些 GTID 场景下会静默忽略 SET GLOBAL，只认配置文件值
在 my.cnf 中正确写入 binlog_format = ROW
写错位置或格式会导致参数被完全忽略，mysqld 启动日志里也不会报错：
- 必须放在
[mysqld]段下，写在[client]或[mysql]段无效 - 写法只能是
binlog_format = ROW（等号前后可有空格），不能是binlog-format = ROW或binlog_format= row（小写、带空格、短横线都会失效） - 如果已有
log-bin配置，确保它也在同一 [mysqld] 段内，否则 binlog 功能本身不启用
重启后验证是否真生效且能写入 binlog
重启成功不代表 binlog_format 就起作用了，常见假阳性：
- 执行
SHOW BINARY LOGS;确认 binlog 文件存在且在滚动（若返回 “You are not using binary logging” 说明log-bin没配或没生效） - 跑一条 UPDATE：
UPDATE your_table SET name = 'test' WHERE id = 1;，再立刻查SHOW MASTER STATUS;—— 如果Position没变，说明该语句根本没记进 binlog（可能是表无主键触发安全降级，或 binlog_format 实际仍是 STATEMENT） - 用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.0000xx | tail -30看最后事件：出现### UPDATE+### WHERE+### SET行，才确认是 ROW 模式在工作
ROW 模式下容易被忽略的磁盘和复制风险
选 ROW 不是设完就完事，它会立刻放大几个关键问题：
- 单条全表 UPDATE 可能生成 GB 级 binlog（比如更新百万行、每行含 TEXT 字段），
max_binlog_size = 128M比默认 1G 更早轮转，防单文件撑爆磁盘 - 从库延迟敏感：ROW 日志解析比 STATEMENT 慢，若从库 IO 或 CPU 已临界，加
slave_parallel_workers = 4（需开启slave_parallel_type = LOGICAL_CLOCK） -
binlog_rows_query_log_events = OFF必须关掉——它默认开，会把原始 SQL 也塞进 binlog，体积翻倍且泄露业务逻辑 - 如果表没有主键，ROW 模式下 MySQL 会自动 fallback 到全字段比对（
@1=@1 AND @2=@2...），此时binlog_row_image = MINIMAL失效，日志体积反而比有主键时更大
真正麻烦的不是设成 ROW，而是设完后没检查从库是否追得上、磁盘是否开始告警、以及有没有人偷偷在无主键表上跑 UPDATE —— 这些问题往往在大促前夜才爆发。
