基于语句的复制的优点

基于语句的复制的缺点

基于行复制的优点

基于行复制的缺点

成熟的技术。

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

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

对SBR不安全的语句。并非所有修改数据的语句(如插入删除，更新,取代语句)可以使用基于语句的复制进行复制。在使用基于语句的复制时，任何不确定性行为都难以复制。这种数据修改语言(DML)语句的例子包括:

使用基于语句的复制无法正确复制的语句将被记录，并发出如下所示的警告:

[警告]使用语句格式登录是不安全的。

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

插入……选择与基于行的复制相比，需要更多的行级锁。

更新语句需要表扫描(因为在在哪里子句)必须锁定比基于行的复制更多的行。

为InnoDB:一个插入语句，使用AUTO_INCREMENT阻塞其他非冲突的插入语句。

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

如果在副本上的计算中出现错误，特别是在执行复杂语句时，基于语句的复制可能会随着时间的推移在受影响的行之间缓慢增加误差幅度。看到第17.5.1.29节“复制过程中的复制错误”．

存储函数使用相同的方法执行现在()值作为调用语句。但是，对于存储过程就不是这样了。

必须在副本上应用确定的可加载函数。

表定义在源和副本上必须(几乎)相同。看到第17.5.1.9节“源和副本的表定义不同的复制”，以查询更多资料。

从MySQL 8.0.22开始，从MySQL授权表读取数据(通过连接列表或子查询)但不修改数据的DML操作在MySQL授权表上执行非锁定读取，因此对于基于语句的复制不安全。有关更多信息，请参见授予表并发性．

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

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

副本上所需的行锁更少插入，更新,或删除声明。

RBR可以生成更多必须记录的数据。复制一个DML语句(例如更新或删除语句)，基于语句的复制只将语句写入二进制日志。相比之下，基于行的复制将每个更改的行写入二进制日志。如果语句更改了许多行，基于行的复制可能会向二进制日志写入大量的数据;即使对于回滚的语句也是如此。这也意味着创建和恢复备份可能需要更多的时间。此外，二进制日志被锁定较长时间以写入数据，这可能导致并发问题。使用binlog_row_image =最小大大减少劣势。

确定性可加载函数，生成大型团与基于语句的复制相比，基于行复制复制值所需的时间更长。这是因为团记录列值，而不是生成数据的语句。

您无法在副本上看到从源接收和执行了哪些语句。但是，您可以看到更改了哪些数据mysqlbinlog有了选项——base64-output = DECODE-ROWS而且——详细．

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

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