语句基于复制的优点

语句基于复制的缺点

行基于复制的优点

行基于复制的缺点

可靠的技术。

写入日志文件的数据量减少。更新或删除多行时，这将导致日志文件所需的存储空间减少。此外，这也意味着可以更快地恢复备份。

日志文件包含所有修改了数据的语句，因此可以用来审核数据库。

语句不安全的SBR。 不是所有修改数据的语句（例如INSERT、DELETE、UPDATE和REPLACE语句）可以使用语句基于复制。任何非确定性行为在使用语句基于复制时很难复制。例如：

不能正确地使用语句复制的语句将以警告形式记录，如下所示：

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

类似警告也将在客户端显示，可以使用SHOW WARNINGS命令显示。

INSERT ... SELECT需要比行级锁定更多的锁定。

UPDATE 语句，如果没有索引在 WHERE 子句中，那么必须锁定更多的行，以便与基于行的复制相比。

对于 InnoDB：使用 AUTO_INCREMENT 的 INSERT 语句将阻止其他非冲突的 INSERT 语句。

对于复杂的语句，语句必须在复制服务器上评估和执行，然后更新或插入行。使用基于行的复制，复制服务器只需要修改受影响的行，而不需要执行完整的语句。

如果在复制服务器上出现错误，特别是在执行复杂语句时，基于语句的复制可能会逐渐增加错误的范围。请参阅第19.5.1.29节，“复制服务器错误”。

存储函数在执行时使用与调用语句相同的 NOW() 值。然而，这不适用于存储过程。

确定的可加载函数必须在复制服务器上应用。

表定义必须在源和复制服务器上几乎相同。请参阅第19.5.1.9节，“源和复制服务器上的不同表定义”，了解更多信息。

DML 操作从 MySQL 授予权表（通过连接列表或子查询）读取数据，但不修改它们，将以非锁定读取的方式在 MySQL 授予权表上执行，因此不安全用于基于语句的复制。了解更多信息，请参阅授予权表并发。

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

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

在复制服务器上，对于任何 INSERT、UPDATE 或 DELETE 语句，需要更少的行锁。

RBR 可能生成更多需要记录的数据。要复制 DML 语句（例如 UPDATE 或 DELETE 语句），语句基于的复制将只将语句写入二进制日志。相比之下，行基于的复制将将每个更改的行写入二进制日志。如果语句更改了许多行，行基于的复制可能将更多的数据写入二进制日志；这也适用于回滚的语句。此外，这也意味着恢复备份可能需要更长的时间。此外，二进制日志将被锁定更长时间，以写入数据，这可能会导致并发问题。使用 binlog_row_image=minimal 可以减少不良影响的程度。

确定的可加载函数，生成大量 BLOB 值的处理速度在行基于的复制中比语句基于的复制慢。这是因为 BLOB 列值被记录，而不是生成数据的语句。

您不能在复制服务器上看到来自源服务器的语句和执行的语句。然而，您可以使用 mysqlbinlog 工具，使用选项 --base64-output=DECODE-ROWS 和 --verbose 查看数据的变化。

或者，您可以使用 binlog_rows_query_log_events 变量，如果启用，将在 mysqlbinlog 输出中添加一个 Rows_query 事件，以便使用 -vv 选项时。

对于使用MyISAM存储引擎的表，需要在复制服务器上对INSERT语句应用时使用更强的锁定，而不是将其应用为语句。这意味着，在使用行基于的复制时，不能支持并发插入MyISAM表。