SET GLOBAL binlog_format仅影响后续新写入事件的格式，不改变已落盘binlog文件的物理结构，因每条event自带不可变格式标识，旧文件保持原始格式不变。
binlog_format 是只读的全局配置项，不是运行时可自由切换的会话变量。它控制的是**新写入事件的格式**，对已落盘的 mysql-bin.0000xx 文件完全无效。
为什么 SET GLOBAL binlog_format = 'STATEMENT' 不影响已有日志？
MySQL 的 binlog 是追加写入的二进制文件，每条 event 都带格式标识（如 Write_rows_v1、Query_event），一旦写入磁盘就不可变。你改 binlog_format 只会让后续事务按新格式生成 event，旧文件仍保持原始结构。
-
SET GLOBAL修改仅影响新连接或后续事务，不重写历史文件 - 从库 SQL 线程解析时，会严格校验每个 event 的 type 和 header，和当前
binlog_format值无关 - 试图用
mysqlbinlog解析旧 ROW 日志却设成 STATEMENT 模式，只会报错或输出乱码，不是“格式没生效”，而是解析器和日志内容不匹配
主从复制中断时，为什么不能靠临时改 format 修复？
错误信息如 The slave is running with binlog_format = STATEMENT, but the master sent a ROW event 表明：主库已发出 ROW 格式 event，从库却用 STATEMENT 模式启动 SQL 线程——这不是配置滞后，而是协议层面不兼容。
- 从库启动时会读取 relay log 中第一个 event 的 format type，并据此初始化解析器；它不看自己
@@global.binlog_format的值 - 如果主库在升级后切为 ROW，而从库没同步改配置、没重启，relay log 里混入 ROW event，SQL 线程直接拒绝执行
-
SET GLOBAL binlog_format对 SQL 线程无作用，它只影响当前会话的写入行为，而复制线程是独立后台线程
哪些操作看似“修改格式”实则无效？
常见误操作包括：
- 只改
my.cnf但忘记restart mysqld→ 配置未加载，SELECT @@global.binlog_format显示旧值 - 主库改了，从库没改 → 复制启动失败，错误明确指向 format 不一致
- 用
FLUSH LOGS以为能“刷新格式” → 它只切换到新 binlog 文件，新文件才用当前 format，旧文件不变 - 误信云厂商控制台“一键切换 binlog 格式” → 实际只是改配置+重启，仍需人工验证主从一致性
my.cnf 中的 binlog_format，重启 MySQL 进程，且主从必须同时完成该动作（滚动升级顺序不能错）。任何绕过重启的操作，都无法改变已存在 binlog 文件的物理格式。 
