MySQL 5.7 升级到 8.0 后 binlog_format 默认变为 MIXED，需显式配置并重启生效；主从必须严格一致，且 ROW 格式下需注意日志膨胀、主键依赖及压缩兼容性问题。
升级后binlog_format被重置为MIXED，服务启动就报错
MySQL 5.7 升级到 8.0 后，binlog_format 默认值从 STATEMENT 变成 MIXED，但如果你的主从复制依赖严格 STATEMENT（比如用了某些不带确定性的时间函数），从库可能直接中断并报 Cannot execute statement: binlogging impossible。
- 检查当前值：
SELECT @@global.binlog_format; - 别只看配置文件——升级后 MySQL 会忽略
my.cnf中未显式声明的binlog_format，必须写进[mysqld]段并重启生效 - 如果用的是 Percona Server 或 MariaDB，注意它们对
ROW的默认行为可能不同，别直接套用官方文档
ROW 格式下 UPDATE 日志暴涨，磁盘撑爆
ROW 格式记录每行变更前后的完整镜像，尤其对大字段（TEXT/BLOB）或批量更新，单条日志可达 MB 级。不是“更安全”就无脑切，得看实际负载。
- 用
SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 10;快速确认日志内容是否含大量Write_rows_v1/Update_rows_v1 - 对低频但大字段表，考虑在业务层拆分操作，避免
UPDATE ... SET blob_col = ?这种全量写入 -
binlog_row_image = MINIMAL能显著压缩日志（只记变更列），但要求所有表有主键或唯一非空索引，否则降级为FULL
主从 binlog_format 不一致导致复制中断
主库是 ROW，从库设成 STATEMENT？不行。反过来也不行。MySQL 8.0 开始校验更严，启动时就拒绝不匹配组合，错误信息是：Slave SQL thread retried a transaction but failed with error: The slave is running with binlog_format = STATEMENT, but the master sent a ROW event。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 主从必须完全一致：不仅
binlog_format，连binlog_row_image和binlog_checksum都要对齐 - 不要靠
SET GLOBAL binlog_format = ...临时改——它只影响当前会话，且从库 SQL 线程不认这个设置 - 滚动升级时，先改从库配置、重启，再改主库，避免中间状态断复制
应用读取 binlog 时解析失败，怀疑格式兼容性
用 mysqlbinlog 解析 8.0 的 binlog，如果提示 unknown compression algorithm 或乱码，大概率是启用了 binlog_transaction_compression = ON（8.0.20+ 默认关闭，但部分云厂商镜像开了）。
- 确认压缩开关：
SELECT @@global.binlog_transaction_compression; - 若为
ON，解析需加参数：mysqlbinlog --binlog-row-event-max-size=8192 --base64-output=DECODE-ROWS --verbose（仍可能失败，建议关掉） - 第三方工具如 Maxwell、Canal 对
ROW+ 压缩支持不一，查清其版本是否适配 8.0.22+ 的新事件头结构
最麻烦的其实是隐式依赖：某个旧存储过程里写了 NOW()，在 STATEMENT 下主从时间差几秒就错；换成 ROW 后又因为没主键，binlog_row_image = MINIMAL 导致从库找不到匹配行。这种链路问题，光调参数没用，得结合 SHOW SLAVE STATUS\G 的 Exec_Master_Log_Pos 定位到具体事件再反查。
