复制特性实施的核心，就是基于Master节点对数据库中各项变更的处理机制。
二进制日志在记录事件时，支持多种格式，由binlog_format参数控制：
SBL对应statement，RBL对应row，MBL对应mixed
在MySQL5.6版本中，默认的日志记录格式是基于语句(Statement)，一般会手动将其改为混合模式(Mixed)，日志记录格式是由binlog_format系统参数控制
默认情况下，MBR是基于语句记录事件，当遇到SBR模式记录事件，存在数据安全隐患时，自动将日志记录格式变更为基于行格式记录，也就是RBR模式
使用SBR的优点：
技术成熟
生成日志少，特别是对于大量更新及删除操作
由于能够记录下数据库做过的所有变更操作，日志可用于行为审计
使用SBR的缺点：
Master节点中产生的修改操作并不是都能通过基于语句方式完整的复制到Slave节点，对于不确定的行为在基于语句复制时，很难确保Slave节点会执行并获得正确的数据
执行INSERT…SELECT语句时需要持有更多行锁(相比RBR而言)
UPDATE时也需要持有更多行锁(相比RBR而言)
对于InnoDB引擎，INSERT语句使用AUTO_INCREMENT会阻塞其他INSERT语句
对于复杂的语句，Slave节点执行时语句必须先被评估
如果在Slave节点执行时操作失败，基于SBR格式复制会增加主从不一致的概率
使用RBR的优点：
所有修改都能被安全地复制到Slave节点
Master端执行修改操作时，仅需极少的锁持有，因此可获得更高的并发特性
Slave节点执行INSERT/UPDATE/DELETE时也仅需要持有少量锁
使用RBR的缺点：
RBR可能会产生更多的日志
不再能通过分析日志，来获取曾经执行过的语句
例子1：有一条复杂的SQL语句，在Master节点执行了一个多小时，才最终成功修改了一条记录。这时候不适宜用SBR模式，应该使用RBR模式
例子2：有条简单的SQL，在Master节点执行时，向库中插入了1000万条记录。这时候不适宜采用RBR模式，应该使用SBR模式