binlog 日志的三种格式?

binlog 日志的三种格式各有优缺点，适用于不同的场景： ### 1. **Statement 格式**（基于 SQL 语句的复制，SBR） - **特点**：每次执行修改数据的 SQL 语句时，直接将该 SQL 语句记录在 binlog 中。 - **优点**： - 记录的是 SQL 语句而不是数据的变更，因此 binlog 文件较小，节约了存储空间。 - 相比 Row 格式，IO 开销较小，性能较好。 - **缺点**： - 由于只记录 SQL 语句，在主从复制时，可能会由于环境差异或执行上下文的不同，导致语句在从库上执行的结果与主库不同，尤其是在涉及非确定性函数（如 `NOW()`）、存储过程、触发器等时。 - 需要记录额外的上下文信息，以确保 SQL 能够在从库上正确执行。 ### 2. **Row 格式**（基于行的复制，RBR） - **特点**：不记录 SQL 语句，而是直接记录哪一行数据被修改，以及被修改后的数据内容。 - **优点**： - 可以精确记录每一行数据的变化，无需关心 SQL 语句的执行环境，从而避免了某些 SQL 语句在主从库之间执行不一致的问题。 - 对于复杂场景，如存储过程、触发器等，能准确地进行复制。 - **缺点**： - 由于记录的是具体的行变更，日志文件会很大，尤其是批量更新或删除操作时，可能会产生大量的 binlog 日志。 - 在高并发和大量写操作的场景下，可能会带来较大的 IO 和存储开销。 ### 3. **Mixed 格式**（混合模式复制，MBR） - **特点**：结合了 Statement 和 Row 两种格式的优点。MySQL 会根据执行的 SQL 语句类型来选择适当的 binlog 记录方式。一般情况下，使用 Statement 格式记录 binlog，但对于某些复杂语句（如非确定性函数、存储过程等），会自动切换为 Row 格式。 - **优点**： - 提供了更好的灵活性，能够根据不同的 SQL 语句选择合适的日志格式。 - 在性能和精确性之间找到平衡，在大部分情况下能够减少 binlog 日志量，同时确保主从复制的准确性。 - **缺点**： - 由于需要动态切换格式，复杂度比单一格式高，可能在某些场景下导致调试困难。 ### 总结： - **Statement** 格式适合需要节省存储空间、日志量小的场景，但在某些复杂语句下可能出现主从不一致问题。 - **Row** 格式能够保证数据的准确性，但日志量大，适合高精度数据同步的需求。 - **Mixed** 格式兼具两者的优点，适合大多数使用场景，尤其是希望在性能和精确性之间取得平衡的情况。