MysQL的binlog三种录入格式详解
一，MysQL的binlog有有几种录入格式?
1，STATEMENT格式
记录Master端执行的原始SQL语句，日志体积小、磁盘占用低，但部分特殊函数（如UUID()）可能导致主从数据不一致。
2，ROW格式
记录每一行数据的具体修改细节，能完全保证主从数据一致，不会出现函数执行结果偏差的问题，但执行ALTER TABLE等批量操作时会生成大量日志，磁盘占用高。
3，MIXED格式
是前两种格式的混合模式，MySQL会自动根据执行的SQL类型，智能选择使用STATEMENT或ROW模式写入日志，兼顾性能与数据一致性。
二，分别有什么区别?
logbin格式:
binlog.format=STATEMENT(默认)∶数据操作的时间，同步时不一致，每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化，减少了binlog日志量，节约IO，提高性能。缺点是在某些情况下会导致master-slave中的数据不一致( 如sleep()函数，last_insert_id()，以及user-defined functions(udf)等会出现问题)
binlcg.format=ROW:批量数据操作时，效率低、不记录每条sql语们的上下文信息，仅需记录哪条数据被修改了，修改成什么样了.而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是alter table的时候会让日志暴涨.
binlog _format=MXED:是以上两种level的混合使用，有函数用ROW，没函数用STATEMENT，但是无法识别系统变量
一、核心特性对比
| 对比维度 | STATEMENT格式 | ROW格式 | MIXED格式 |
|---|---|---|---|
| 记录方式 | 记录原始执行的SQL语句 | 记录每行数据变更前后的镜像 | 自动选择前两种模式写入 |
| 日志体积 | 体积小，节省磁盘与网络带宽 | 体积大，批量更新会生成大量行记录 | 兼顾体积，动态适配 |
| 主从一致性 | 存在非确定性函数导致数据不一致的风险 | 完全保证主从数据一致 | 绝大多数场景下数据一致 |
| 可读性 | 直接可读，可直接解析SQL内容 | 需专用工具解析行变更细节 | 可读性随写入模式动态变化 |
二、优缺点与适用场景
STATEMENT格式
- 优点：日志量小、解析简单、兼容性强，所有MySQL版本均支持
- 缺点：遇到UUID()、NOW()、RAND()等非确定性函数，或无ORDER BY的LIMIT操作时，主从重放结果会出现偏差
- 适用场景：磁盘空间敏感、业务无复杂非确定性函数的老旧系统
ROW格式
- 优点：复制精准无歧义，支持数据闪回，行级冲突检测更适配并行复制
- 缺点：批量更新大表时会生成海量日志，磁盘占用高
- 适用场景：生产环境主流推荐，对主从数据一致性要求极高的核心业务
MIXED格式
- 优点：MySQL自动根据SQL类型选择写入模式，简单操作用STATEMENT减少日志量，复杂自动切换为ROW保障一致性
- 缺点：部分特殊场景下仍可能出现小概率的主从同步异常
- 适用场景：对性能和一致性要求都不极端，希望平衡两者优势的通用业务系统
三、生产选型总结
- 核心金融、交易类业务优先选ROW格式，彻底规避数据不一致风险
- 日志存储资源紧张、业务逻辑简单的场景可选用STATEMENT格式
- 大部分通用业务场景，MIXED格式是兼顾性能与稳定性的折中选择
三，怎么设置MySQL的binlog格式
设置 MySQL 的 binlog（二进制日志）格式主要有两种方法：通过修改配置文件（推荐，永久生效）和通过 SQL 命令动态修改（临时生效或特定版本支持）。
以下是具体的操作步骤和三种格式的说明：
1. 修改配置文件（推荐）
这是最常用且稳定的方式，修改后需重启 MySQL 服务才能生效。
步骤：
- 找到 MySQL 的配置文件
my.cnf（Linux）或my.ini（Windows）。 - 在
[mysqld]节点下添加或修改binlog_format参数。 - 保存文件并重启 MySQL 服务。
配置示例：
[mysqld] # 设置 binlog 格式为 MIXED（混合模式） binlog_format = mixed # 其他相关常见配置 log-bin = /data/mysql/logs/mysql-bin.log # 指定日志路径 expire_logs_days = 7 # 日志保留天数 max_binlog_size = 100m # 单个日志文件最大大小2. 使用 SQL 命令动态修改
如果你不方便重启服务，或者只需要临时更改当前会话或全局的 binlog 格式，可以使用 SQL 命令。
注意：
- 修改全局变量通常要求 MySQL 5.6 及以上版本支持在线修改部分全局变量，但
binlog_format的在线修改行为可能因版本而异，建议查阅具体版本文档。 - 动态修改仅对修改后新产生的 binlog 事件有效，且可能在主从复制环境中导致不一致，需谨慎操作。
命令示例：
-- 查看当前 binlog 格式 SHOW VARIABLES LIKE 'binlog_format'; -- 设置全局 binlog 格式（需要 SUPER 或 BINLOG_ADMIN 权限） SET GLOBAL binlog_format = 'ROW'; -- 设置当前会话的 binlog 格式 SET SESSION binlog_format = 'STATEMENT';3. Binlog 三种格式的选择建议
MySQL 支持三种 binlog 格式，各有优缺点，可根据业务场景选择：
| 格式 | 说明 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| STATEMENT | 基于 SQL 语句的记录 | 日志量少，节省磁盘 I/O，性能较高 | 在某些特定函数（如UUID(),NOW(),LAST_INSERT_ID()）或存储过程下，主从数据可能不一致 | 对性能要求极高，且 SQL 语句确定性强的场景 |
| ROW | 基于行数据的记录 | 数据一致性最高，能准确复制每一行的变化，避免特定函数导致的主从不一致 | 日志量大，尤其是执行ALTER TABLE或大批量更新时，磁盘 I/O 压力大 | 对数据一致性要求高，或使用大量不确定函数的场景（默认推荐） |
| MIXED | 混合模式 | 结合两者优点。一般情况用 STATEMENT，遇到不确定操作自动切换为 ROW | 配置稍复杂，需 MySQL 智能判断 | 通用推荐。既保证了大多数情况下的高性能，又在必要时保证一致性 |
4. 验证设置是否成功
设置完成后，可以通过以下命令检查当前生效的 binlog 格式：
SHOW VARIABLES LIKE 'binlog_format';输出结果应显示你设置的值（如ROW、STATEMENT或MIXED）。
总结建议
- 生产环境推荐：使用
MIXED 或 ROW 格式，以确保主从复制的数据一致性。 - 性能敏感场景：如果确认 SQL 语句没有不确定性因素，可考虑
STATEMENT以减少日志体积。 - 操作前备份：修改核心配置前，建议先备份配置文件，并在测试环境验证后再应用到生产环境。