基于语句的复制的优点

基于语句的复制的缺点

基于行的复制的优点

基于行的复制的缺点

成熟的技术。

写入日志文件的数据较少。当更新或删除影响许多行时，这会导致 日志文件所需的存储空间大大减少。这也意味着可以更快地完成备份和恢复。

日志文件包含进行任何更改的所有语句，因此它们可用于审核数据库。

对 SBR 不安全的语句。  并非所有修改数据的语句（例如 、 和 语句）都可以使用基于语句的复制进行复制。使用基于语句的复制时，任何不确定的行为都难以复制。此类数据修改语言 (DML) 语句的示例包括： INSERT DELETEUPDATEREPLACE

无法使用基于语句的复制正确复制的语句会被记录为警告，如下所示：

[Warning] Statement is not safe to log in statement format.

在这种情况下，也会向客户端发出类似的警告。客户端可以使用 SHOW WARNINGS.

INSERT ... SELECT与基于行的复制相比，需要更多的行级锁。

UPDATE需要表扫描的语句（因为 WHERE子句中没有使用索引）必须锁定比基于行的复制更多的行。

For InnoDB： INSERT使用 AUTO_INCREMENT块其他非冲突语句的INSERT 语句。

对于复杂语句，必须在更新或插入行之前在副本上评估和执行该语句。使用基于行的复制，副本只需要修改受影响的行，而不是执行完整的语句。

如果对副本的评估存在错误，特别是在执行复杂语句时，基于语句的复制可能会随着时间的推移慢慢增加受影响行的误差幅度。请参阅 第 17.5.1.29 节，“复制期间的副本错误”。

存储函数以与 NOW()调用语句相同的值执行。但是，存储过程并非如此。

确定性可加载函数必须应用于副本。

源和副本上的表定义必须（几乎）相同。有关详细信息，请参阅 第 17.5.1.9 节，“在源和副本上使用不同的表定义进行复制”。

从 MySQL 8.0.22 开始，从 MySQL 授权表（通过连接列表或子查询）读取数据但不修改它们的 DML 操作作为对 MySQL 授权表的非锁定读取执行，因此对于基于语句的语句不安全复制。有关详细信息，请参阅 授予表并发性。

所有更改都可以复制。这是最安全的复制形式。

对于以下类型的语句，源上需要更少的行锁，从而实现更高的并发性：

INSERT对于任何、 UPDATE或 DELETE语句 ， 副本上需要的行锁更少 。

RBR 可以生成更多必须记录的数据。要复制 DML 语句（例如 UPDATEor DELETE语句），基于语句的复制仅将语句写入二进制日志。相比之下，基于行的复制将每个更改的行写入二进制日志。如果该语句更改了很多行，则基于行的复制可能会将更多数据写入二进制日志；即使对于回滚的语句也是如此。这也意味着制作和恢复备份可能需要更多时间。另外，二进制日志写入数据的时间较长，可能会导致并发问题。利用 binlog_row_image=minimal大大减少劣势。

生成大 BLOB值的确定性可加载函数使用基于行的复制比使用基于语句的复制花费更长的时间进行复制。这是因为 BLOB记录的是列值，而不是生成数据的语句。

您无法在副本上看到从源接收并执行了哪些语句。但是，您可以使用带有选项 和的mysqlbinlog查看更改了哪些数据。 --base64-output=DECODE-ROWS--verbose

或者，使用 binlog_rows_query_log_events 变量，如果启用，则 在使用该选项 时将Rows_query带有语句的事件添加到 mysqlbinlog输出 。-vv

对于使用存储引擎的表，当将它们作为基于行的事件应用到二进制日志时，比将它们作为语句应用时，语句MyISAM 的副本需要更强的锁。INSERT这意味着MyISAM使用基于行的复制时不支持对表进行并发插入。