MySQL的binlog即二进制日志，是记录数据库所有数据变更操作的重要日志文件，而Mixed是MySQL提供的三种binlog格式之一，结合了STATEMENT和ROW两种格式的特点，在不同场景下自动选择最合适的日志记录方式。
Mixed日志格式的基本定义
Mixed格式的binlog是STATEMENT和ROW两种日志格式的混合体，MySQL会根据执行的SQL语句类型，自动判断使用哪种格式记录日志。它的设计初衷是兼顾STATEMENT格式的高性能和ROW格式的高数据一致性，避免单一格式的缺陷。
Mixed格式的日志记录规则
Mixed格式并不是随机切换记录方式，而是有明确的判断逻辑：
- 当执行的SQL语句可以被安全地以STATEMENT格式记录时，就会使用STATEMENT格式，比如简单的INSERT、UPDATE、DELETE操作，不涉及不确定函数。
- 当SQL语句存在不确定性因素，使用STATEMENT格式可能导致主从数据不一致时，会自动切换为ROW格式记录，比如使用了UUID()、NOW()等不确定函数，或者使用了用户自定义函数。
判断逻辑的示例说明
以下面的SQL为例，当执行确定性的更新操作时，Mixed格式会使用STATEMENT记录：
-- 确定性更新，使用STATEMENT格式记录 UPDATE user SET age = age + 1 WHERE id = 1;
而当SQL中包含不确定函数时，就会切换为ROW格式：
-- 包含NOW()不确定函数，切换为ROW格式记录
INSERT INTO log (content, create_time) VALUES ('test', NOW());Mixed与另外两种格式的差异对比
三种binlog格式的核心差异可以通过下表清晰展示：
| 对比项 | STATEMENT格式 | ROW格式 | Mixed格式 |
|---|---|---|---|
| 记录内容 | 记录原始SQL语句 | 记录每行数据的具体变更 | 自动选择STATEMENT或ROW格式 |
| 日志大小 | 较小 | 较大 | 介于两者之间 |
| 主从一致性 | 存在不一致风险 | 一致性高 | 一致性较高 |
| 性能影响 | 较小 | 较大 | 介于两者之间 |
Mixed格式的使用场景
Mixed格式适合大多数常规的业务场景，尤其是以下情况：
- 业务中存在部分不确定函数的使用，但不想完全使用ROW格式导致日志量过大。
- 主从复制架构中，需要平衡日志大小和主从数据一致性。
- 日常增量备份场景，既需要快速恢复，又需要保证备份数据的准确性。
使用Mixed格式的注意事项
虽然Mixed格式结合了两种格式的优点，但使用时也需要注意以下问题：
- 需要明确业务中哪些SQL会触发ROW格式记录，避免意外的日志量暴涨。
- 在MySQL 5.7及之前版本，部分复杂场景下的判断逻辑可能存在边界情况，需要提前测试。
- 如果业务对数据一致性要求极高，且日志量可以接受，也可以直接选择ROW格式，避免Mixed格式的自动切换带来的不确定性。
查看和配置Mixed格式
可以通过以下SQL查看当前binlog格式：
-- 查看当前binlog格式 SHOW VARIABLES LIKE 'binlog_format';
如果需要将binlog格式设置为Mixed，可以执行以下命令：
-- 设置当前会话的binlog格式为Mixed SET SESSION binlog_format = 'MIXED'; -- 设置全局binlog格式为Mixed，需要重启连接生效 SET GLOBAL binlog_format = 'MIXED';
需要注意的是，修改全局binlog_format后，已经存在的连接不会立即生效，只有新建立的连接会使用新的格式，正式环境修改建议结合业务低谷期操作。
MySQLMixed_binlogbinlog_format数据库主从复制修改时间：2026-06-06 23:15:51