mysql 8.0 默认强制使用row格式，非建议而是硬编码行为；必须在my.cnf的[mysqld]段显式配置binlog_format=row并重启生效，主从需严格一致，否则复制中断或cdc工具解析失败。
MySQL 8.0 默认 ROW 是强制行为，不是建议而是事实
MySQL 8.0 启动时若 my.cnf 中未显式配置 binlog_format，会直接设为 ROW —— 这不是“推荐”，是硬编码行为。你查 SELECT @@global.binlog_format 看到 ROW，不代表配置生效了，只说明当前运行值；真正起作用的是配置文件里有没有那行 binlog_format = ROW。
常见错误现象：升级 5.7 → 8.0 后复制中断、CDC 工具解析失败、mysqlbinlog 输出乱码或报错 unknown compression algorithm —— 往往不是格式错了，而是没配、配错位置（比如写在 [client] 段），或主从配置不一致。
-
binlog_format必须放在[mysqld]段下，且等号前后不能有空格 - 云厂商镜像可能默认开启
binlog_transaction_compression = ON，导致本地mysqlbinlog解析失败，需加--binlog-row-event-max-size参数或关压缩 - 旧从库（如 MySQL 5.7）无法识别 8.0.33+ 的
Write_rows_event_v2，必须核对官方 “Replication Compatibility” 表
STATEMENT 格式在 8.0 下会被主动拦截，不是兼容性问题而是安全策略
MySQL 8.0 对 STATEMENT 不再宽容：执行 INSERT ... SELECT 带子查询、启用 GTID、主从 sql_mode 不一致（比如主库开了 STRICT_TRANS_TABLES 而从库没开），都会触发拒绝记录，报错 Statement is not safe to log in statement format。
这不是 bug，是设计使然 —— 它宁可中断写入，也不让不安全日志进入 binlog。你看到这个错误，说明语句本身已具备非确定性风险（比如含 NOW()、RAND()、UUID()、LIMIT 无 ORDER BY），强行用 STATEMENT 只会让主从数据分叉。
- 含
@variable或未声明DETERMINISTIC的自定义函数，也会被拦截 - 即使语句能过，从库重放时也可能因索引选择差异（主库走
age索引，从库走modified_time）、执行延迟（LIMIT 10删的行不同）导致数据错位 -
MIXED模式不会帮你兜底：它靠内置规则表硬匹配，规则不覆盖你的业务逻辑，误判率高，且不提示切换动作
ROW 格式支撑现代数据链路，不是“可选”而是“必需”
你用 Canal、Flink CDC、ShardingSphere 或 Maxwell 做增量同步？它们全依赖 ROW 日志里的行级变更快照。STATEMENT 日志里只有 SQL 文本，没有 before-image 和 after-image，这类工具要么无法启动，要么得额外引入 SQL 解析器 —— 精度低、性能差、维护成本高。
审计与误操作恢复也强依赖 ROW：mysqlbinlog --base64-output=DECODE-ROWS -v 能直接看到被删的每一行原始数据；配合默认的 binlog_row_image = FULL，哪怕 UPDATE 只改一个字段，也能还原整行旧值，支持精准闪回。
-
slave_parallel_type = LOGICAL_CLOCK并行复制必须基于 ROW 事件才能正确分发事务 - 无主键表在 ROW 模式下会严重拖慢复制（全表扫描匹配），这是唯一真坑，必须提前补主键
-
binlog_row_image = MINIMAL可减少日志体积（只记变更列），但部分 CDC 工具要求FULL，上线前务必确认兼容性
sync_binlog = 1 不等于 crash-safe，ROW 配置必须搭配 innodb_flush_log_at_trx_commit
只设 binlog_format = ROW 不够，sync_binlog = 1 也只保 binlog 不丢。若没同步配 innodb_flush_log_at_trx_commit = 1，主库 crash 后可能丢失已提交但未刷盘的 redo log，造成主从数据不一致 —— 这是 ROW 模式下最常被忽略的配套项。
线上压测发现 I/O 压力大？可权衡设 sync_binlog = 100，但要接受最多丢失最近 99 个事务的 binlog；同时必须确保 expire_logs_days 和 max_binlog_size 配合 FLUSH LOGS 使用，否则 binlog 文件堆积不清理。
- 主从都必须严格一致：主库改完，先滚动改从库，再动主库，避免
The slave is running with binlog_format = STATEMENT, but the master sent a ROW event - 多源复制场景下，每个 CHANNEL 要单独验证：
SHOW SLAVE STATUS FOR CHANNEL 'xxx' -
FLUSH LOGS在主库改完格式后必须立即执行，生成新 binlog 文件，防止混用格式日志
mysqlbinlog 输出，都是真实数据变更的镜像，没法靠“猜”绕过去。
