必须修改配置文件并重启mysqld才能使binlog_format=row真正生效；set global仅临时覆盖新连接，重启即失效，且8.0.33+在gtid下会静默忽略该命令。
必须改配置文件并重启mysqld，SET GLOBAL只是临时覆盖
SET GLOBAL binlog_format = 'ROW' 看似生效，但只影响新建立的连接，且重启后立即丢失；已有活跃事务、长连接、连接池中复用的连接仍按旧格式记录。生产环境一旦出现主从不一致或恢复失败，根本原因常是误以为“设过了”。
实操要点：
- 编辑
/etc/my.cnf或/etc/mysql/my.cnf，确保写在[mysqld]段下，且格式严格为binlog_format = ROW（等号前后可空格，但不能用短横线、小写 row、或带引号） - 确认同一
[mysqld]段内已启用log_bin，否则 binlog 功能本身不启动 - 执行
systemctl restart mysqld（或对应服务名），不是 reload
验证必须查全局值 + 解析真实binlog事件
只执行 SHOW VARIABLES LIKE 'binlog_format' 不可靠——它可能返回 ROW，但实际生效的是 session 级旧值；更糟的是，MySQL 8.0.33+ 在 GTID 启用时会静默忽略 SET GLOBAL，只认配置文件。
真正有效的验证步骤：
- 运行
SELECT @@global.binlog_format;，返回必须是ROW（大小写敏感） - 执行
SHOW BINARY LOGS;确认 binlog 文件存在且在滚动 - 对一张有主键的表执行简单更新：
UPDATE t SET c = c + 1 WHERE id = 1; - 立刻执行
SHOW MASTER STATUS;，观察Position是否增加；若不变，说明该语句未记入 binlog（可能是无主键表触发安全降级） - 用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.0000xx | tail -20查看末尾，出现### UPDATE+### WHERE+### SET行，才确认是 ROW 模式在工作
ROW模式下必须同步调整binlog_row_image和磁盘策略
默认 binlog_row_image = FULL 会记录整行变更前后的全部字段，对含 TEXT/BLOB 的表或批量 UPDATE，单条事务日志可达 GB 级，极易撑爆磁盘或拖慢从库解析。
权衡建议：
- 仅需主从复制、不依赖闪回或 CDC 工具 → 改为
binlog_row_image = MINIMAL（只存主键 + 变更列） - 需要审计、数据恢复、Debezium/Canal 同步 → 必须保持
FULL，并监控max_binlog_size（建议设为100M而非默认1G，防单文件失控） - 避免
NOBLOB，除非你明确知道所有 BLOB 字段都不参与业务逻辑且下游完全不消费 - 配合
binlog_expire_logs_seconds = 604800（7天），防止从库 IO 线程因日志被清理而报错Got fatal error 1236
ROW不是设完就高枕无忧，它放大了sync_binlog和innodb_flush_log_at_trx_commit的耦合风险
ROW 模式本身不改变崩溃一致性保障逻辑，但它让 binlog 内容更关键——一旦 binlog 记了某行变更，而 InnoDB redo log 没落盘，主库崩溃后从库就会多出数据；反之，redo 落盘了但 binlog 没刷盘，从库就少数据。
所以：
- 金融、订单类系统：必须同时设
sync_binlog = 1和innodb_flush_log_at_trx_commit = 1 - 普通业务：可设
sync_binlog = 100（每100个事务刷一次），但需接受极小概率的主从差异 - 云数据库（如阿里云 RDS）通常默认关闭
sync_binlog，靠底层存储多副本兜底，自建环境切勿照搬
真正的难点不在“怎么设成 ROW”，而在于：你是否清楚每一处配置改动后，binlog 日志里实际写进去的是什么，以及当主库宕机、从库延迟、或者需要闪回一条误删语句时，那些字节是否真能还原出你要的那一行。
