MySQL的二进制日志（Binary Log，简称binlog）是一种重要的机制，用于记录数据库的所有更改操作，包括数据的插入、更新、删除等。这些记录主要用于数据恢复、备份以及主从复制。MySQL提供了三种不同的binlog_format模式来控制二进制日志中记录数据更改的方式。这三种模式分别是：
- Statement-Based Replication (SBR,
STATEMENT模式):
- 在这种模式下，MySQL将每个改变数据的SQL语句（如
INSERT,UPDATE,DELETE,CREATE TABLE,DROP TABLE等）按原样记录到binlog中。复制时，从服务器直接执行相同的SQL语句来实现与主服务器的数据同步。 - 优点:
- 记录相对简洁，日志量较小，减少了网络传输和磁盘存储的压力。
- 对于简单的数据变更，复制效率较高。
- 缺点:
- 可能导致复制不一致性：如果SQL语句依赖于特定的服务器状态（如系统变量、用户定义变量、非确定性函数如
NOW()或RAND()等），在从服务器上执行同样的语句可能产生不同的结果，造成数据不一致。 - 不适用于某些复杂语句：如包含用户定义函数（UDF）、临时表、存储过程等的语句，在复制过程中可能无法正确处理。
- 触发器和存储过程的副作用：在某些情况下，触发器或存储过程可能在主从服务器上产生不同的副作用，导致数据不一致。
- Row-Based Replication (RBR,
ROW模式):
- 在ROW模式下，binlog不再记录SQL语句，而是记录每一行数据在执行前后的具体变化。每条日志记录包含表名、行ID（通常是主键）以及发生变化的列值。
- 优点:
- 复制一致性高：由于记录的是数据的实际变化，而不是执行的语句，消除了因服务器状态差异或非确定性函数导致的复制不一致问题。
- 更广泛的支持：能够精确地复制所有类型的SQL语句，包括那些在SBR模式下可能导致问题的复杂语句、UDF、临时表等。
- 更便于审计和故障排查：可以直接看到数据的具体变化，有助于详细分析数据历史和定位问题。
- 缺点:
- 日志量大：相较于SBR，ROW模式记录的数据更为详细，日志文件通常更大，需要更多的存储空间，并且在网络传输时消耗更多带宽。
- 解析复杂：从服务器在应用日志时需要解析详细的行级变化，可能比直接执行SQL语句更耗时。
- 对DDL操作处理复杂：对于表结构更改（如
ALTER TABLE），ROW模式下的处理逻辑比SBR更为复杂。
- Mixed-Based Replication (MBR,
MIXED模式):
- MIXED模式是前两种模式的折衷方案。在这种模式下，MySQL会根据SQL语句的性质自动选择使用SBR还是RBR。对于那些在SBR模式下不会导致复制问题的简单、确定性语句，MySQL使用SBR记录；而对于可能引发复制不一致或无法正确复制的复杂语句，则使用RBR模式记录。
- 优点:
- 灵活性：结合了SBR和RBR的优点，既能减少日志量，又能在复杂场景下保证复制一致性。
- 自动化：无需手动选择日志格式，MySQL会自动判断并选择合适的记录方式。
- 缺点:
- 复杂性：由于模式切换的自动性，可能导致难以预测的复制行为，特别是在遇到边界情况或特定SQL组合时。
- 潜在的不一致性风险：尽管大多数情况下能自动选择正确的记录方式，但仍有极少数情况可能出现判断失误，导致复制问题。
总结来说，选择哪种binlog_format模式取决于具体的业务需求、数据库操作的复杂性、对复制一致性的要求以及系统的存储和网络资源。在现代MySQL版本中，由于ROW模式能提供更高的复制一致性且能处理更复杂的SQL场景，它往往被视为最佳实践，尤其是在涉及到大量复杂事务处理和数据复制的环境中。然而，对于日志大小和网络带宽非常敏感且数据操作相对简单的场景，STATEMENT或MIXED模式可能是更合适的选择。在实际应用中，应根据实际情况评估并测试不同的binlog_format模式，以找到最适合自己的解决方案。
