MySQL 5.7 中，详解Server层二进制日志格式

详细解释

MySQL 的二进制日志（Binary Log）支持三种格式：

1. STATEMENT

   • 记录 SQL 语句本身（如 UPDATE users SET age=30 WHERE id=5）。
   • 优点：日志体积小，复制效率高。
   • 缺点 ：某些非确定性操作（如 NOW()、RAND()）在从库可能产生不一致结果。

2. ROW（默认）

   • 记录数据行的实际变更（如 UPDATE users SET age=30 WHERE id=5 → 记录 id=5 的行修改前后的值）。
   • 优点：保证主从数据一致性，适合事务安全要求高的场景。
   • 缺点：日志体积较大（尤其是批量操作时）。

3. MIXED

   • 混合模式：默认记录 STATEMENT，但对非确定性操作自动切换为 ROW。
   • 优点：平衡日志体积和一致性。
   • 缺点：复杂场景下仍需手动干预。

---

为什么默认是 ROW？

• 数据一致性 ：ROW 格式避免了非确定性 SQL 引发的复制不一致问题（如使用 UUID() 或系统函数）。
• 事务安全：与 InnoDB 的事务特性（如 MVCC）兼容性更好。
• 官方推荐 ：自 MySQL 5.1 后逐步转向 ROW，5.7 正式设为默认。

---

查看当前二进制日志格式

SHOW VARIABLES LIKE 'binlog_format';

输出示例：

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+

---

修改二进制日志格式

1. 临时修改（重启失效）：

   SET GLOBAL binlog_format = 'STATEMENT'; -- 或 'MIXED'

2. 永久修改 ：

   在 my.cnf（Linux）或 my.ini（Windows）配置文件中添加：

   [mysqld]
   binlog_format = MIXED

   • 修改后需重启 MySQL 服务生效。

---

注意事项

• 主从复制：若主从库格式不一致，可能导致复制中断。
• 存储引擎 ：ROW 格式对 InnoDB 支持最佳，MyISAM 可能有限制。
• 性能影响 ：ROW 格式的日志量较大，可能增加 I/O 压力，需权衡存储和一致性需求。