绝大多数新项目应选 ROW，因其复制精确、审计友好且兼容 GTID；STATEMENT 已不推荐，8.0 中部分场景自动降级为 ROW，并可能因非确定函数报错；MIXED 行为难预测，不建议生产使用。
binlog_format 选 ROW 还是 STATEMENT？
绝大多数新项目直接选 ROW，除非你明确依赖基于语句的复制（比如老系统里大量用 UUID()、NOW() 等非确定函数且没做特殊处理）。STATEMENT 在 MySQL 5.7+ 已被标记为“不推荐”，8.0 中部分场景会自动降级为 ROW，还可能触发 Unsafe statement 警告甚至报错。
常见错误现象：Binary log is not open 不是格式问题，但 binlog_format=STATEMENT 下执行 INSERT ... SELECT 带子查询时，可能报 Statement is not safe to log in statement format —— 这不是 bug，是 MySQL 主动拒绝记录不可靠语句。
-
ROW：记录每行数据变更前后的镜像，复制精确、审计友好，但日志体积大，尤其批量更新时 -
STATEMENT：记录原始 SQL，日志小，但要求主从执行环境完全一致（比如时间、自增 ID、临时表），否则复制断裂 -
MIXED：MySQL 自动切换，实际行为难预测，调试和排查成本高，不建议生产使用
修改 binlog_format 的正确时机和方式
不能只改配置文件就以为生效了。MySQL 启动时读取 my.cnf 中的 binlog_format，但运行中可通过 SET 动态修改——不过这只影响当前会话或全局 session 级别，**重启后丢失**，且对已开启事务无效。
真正生效的路径只有一条：改配置 + 重启 mysqld。线上环境务必确认从库已同步追平、无延迟，再滚动重启。
- 配置项写法必须是
binlog_format = ROW（等号前后可有空格，但不能写成binlog-format或binlog_format= row） - 配置位置：必须在
[mysqld]段下，写在[client]或其他段无效 - 验证是否生效：
SELECT @@global.binlog_format;，不是@@session.binlog_format
ROW 格式下容易被忽略的磁盘和性能影响
binlog_format=ROW 会让二进制日志体积显著增大，特别是对 UPDATE / DELETE 大表操作：一条语句可能生成几百 KB 甚至 MB 级日志（取决于匹配行数和字段长度）。这不是异常，是设计如此。
典型踩坑点：磁盘突然爆满，查 /var/lib/mysql 发现 mysql-bin.000xxx 单个超 1GB，而之前都是百 MB 级。此时不是日志没清理，而是写入量真实变大了。
- 务必配好
expire_logs_days或binlog_expire_logs_seconds（MySQL 8.0.11+），避免堆积 - 避免在业务高峰期执行全表更新，ROW 模式下它会把每一行旧值+新值都记进 binlog
- 如果用
pt-table-sync或类似工具校验数据，ROW 日志能提供更准的变更溯源，但解析成本也更高
GTID 开启后 binlog_format 的隐性约束
启用 gtid_mode=ON 时，MySQL 强制要求 binlog_format=ROW 或 MIXED，但 MIXED 在 GTID 下行为更不可控，所以实际上等于只能选 ROW。
如果你看到 ERROR 1786 (HY000): Statement violates GTID consistency，大概率是因为用了 CREATE TEMPORARY TABLE、INSERT ... SELECT 带函数，或 binlog_format=STATEMENT 与 GTID 共存 —— 后者在 MySQL 5.7.6+ 会直接启动失败。
- 检查 GTID 状态：
SELECT @@gtid_mode, @@binlog_format; - 不要试图用
SET SESSION binlog_format=STATEMENT绕过限制，GTID 下该语句本身就会报错 - 临时表操作尽量改用普通表 + 命名空间隔离，避免触发 GTID 不安全判定
