每种二进制日志格式都有优点和缺点。对于大多数用户，混合复制格式提供了数据完整性和性能的最佳组合。但是，如果您希望在执行某些任务时利用特定于基于语句或基于行的复制格式的功能优势，则可以使用本节中的信息，其中总结了它们的相对优点和缺点，以确定哪一个最适合您的需求
- 基于语句的复制的优点
- 成熟的技术
- 写入日志文件的数据较少。当更新或删除影响许多行时，这会导致日志文件所需的存储空间大大减少。这也意味着从备份中获取和恢复可以更快地完成。
- 日志文件包含进行任何更改的所有语句，因此可用于审核数据库。
- 基于语句的复制的缺点
- Statements that are unsafe for SBR.并非所有修改数据的语句（例如INSERT DELETE，UPDATE和REPLACE语句）都可以使用基于语句的复制进行复制。使用基于语句的复制时，任何非确定性行为都难以复制。此类数据修改语言（DML）语句的示例包括以下内容：
- 依赖于UDF或不确定的存储程序的语句，因为这样的UDF或存储程序返回的值或取决于提供给它的参数以外的因素。(但是，基于行的复制只是复制UDF或存储程序返回的值，因此它对表行和数据的影响在master和slave上都是相同的。)更多信息请看 Section 16.4.1.16, “Replication of Invoked Features”
- 不带ORDER BY的LIMIT子句的DELETE和UPDATE语句是不确定的。更多信息请看Section 16.4.1.17, “Replication and LIMIT”.
- 必须在slaves上应用确定性UDF
- 使用基于语句的复制无法正确复制使用以下任何方法的语句：
- LOAD_FILE()
- UUID(), UUID_SHORT()
- USER()
- FOUND_ROWS()
- SYSDATE() (unless both the master and the slave are started with the --sysdate-is-now option)
- GET_LOCK()
- IS_FREE_LOCK()
- IS_USED_LOCK()
- MASTER_POS_WAIT()
- RAND()
- RELEASE_LOCK()
- SLEEP()
- VERSION()
- 但是，使用基于语句的复制（包括NOW()等）可以正确复制所有其他函数。更多信息请看Section 16.4.1.15, “Replication and System Functions”.
- 使用基于语句的复制无法正确复制的语句将记录如下所示的警告
- [Warning] Statement is not safe to log in statement format.
- 在这种情况下，也会向客户端发出类似的警告。 客户端可以使用SHOW WARNINGS显示它
- INSERT ... SELECT需要比基于行的复制更多的行级锁
- 需要进行表扫描的UPDATE语句（因为WHERE子句中没有使用索引）必须锁定比基于行的复制更多的行
- 对于InnoDB：使用AUTO_INCREMENT的INSERT语句会阻止其他非冲突的INSERT语句
- 对于复杂语句，必须在更新或插入行之前在slave上评估和执行该语句。对于基于行的复制，slave只需修改受影响的行，而不是执行完整语句。
- 如果在对slave的评估中出现错误，特别是在执行复杂语句时，基于语句的复制可能会随着时间的推移逐渐增加受影响行的误差范围，更多信息请看Section 16.4.1.28, “Slave Errors During Replication
- 存储函数执行时与调用语句的NOW()值相同。但是，存储过程不是这样的。
- 表定义在master和slave上必须（几乎）相同。更多信息请看Section 16.4.1.10, “Replication with Differing Table Definitions on Master and Slave”
- 基于行的复制的优点
- 可以复制所有更改。 这是最安全的复制形式。
- 注意：
- 更新mysql数据库中的信息的语句（如GRANT，REVOKE和触发器操作，存储的例程（包括存储过程）和视图）都使用基于语句的复制复制到slave上
- 对于诸如CREATE TABLE ... SELECT之类的语句，将从表定义生成CREATE语句并使用基于语句的格式进行复制，而行插入使用基于行的格式进行复制。
- 对于以下类型的语句，master上需要更少的行锁，从而实现更高的并发性
- 对于以下类型的语句，master上需要更少的行锁，从而实现更高的并发性
- INSERT ... SELECT
- INSERT statements with AUTO_INCREMENT
- UPDATE or DELETE statements with WHERE clauses that do not use keys or do not change most of the examined rows.
- 对于任何INSERT，UPDATE或DELETE语句，slave需要更少的行锁。
- 基于行的复制的缺点
- RBR会生成更多必须记录的数据。要复制DML语句（例如UPDATE或DELETE语句），基于语句的复制仅将语句写入二进制日志。相比之下，基于行的复制将每个更改的行写入二进制日志。如果语句更改了许多行，则基于行的复制可能会将更多数据写入二进制日志; 即使对于回滚的语句也是如此。这也意味着制作和恢复备份可能需要更多时间。此外，二进制日志被锁定较长时间来写入数据，这可能会导致并发问题。使用binlog_row_image = minimal来显著减少缺点。
- 与基于语句的复制相比，使用基于行的复制生成大型BLOB值的确定性UDF需要更长的时间来复制。这是因为记录了BLOB列值，而不是生成数据的语句。
- 您无法在slave上看到从master接收和执行的语句。但是，您可以使用mysqlbinlog以及--base64-output = DECODE-ROWS和--verbose选项查看更改了哪些数据。 或者，使用binlog_rows_query_log_events变量，如果启用，则在使用-vv选项时将该语句添加到mysqlbinlog输出的Rows_query事件。
- 对于使用MyISAM存储引擎的表，当将INSERT语句作为基于行的事件应用于二进制日志而不是将它们作为语句应用时，INSERT语句的slave需要更强的锁。这意味着在使用基于行的复制时，不支持在MyISAM表上进行并发插入。
参考链接：https://dev.mysql.com/doc/refman/5.7/en/replication-sbr-rbr.html
PREV:6:多源复制的实现 https://blog.51cto.com/itzhoujun/2353940
