除以下几种环境外，在运行时可以动态改变 binlog 的名目：
. 存储流程可能触发器中间；
. 启用了 NDB；
. 当前会话利用 row 模式，而且已打开了姑且表；
假如 binlog 回收了 Mixed 模式，那么在以下几种环境下会自动将 binlog 的模式由 statement 模式变为 row 模式：
. 当 DML 语句更新一个 NDB 表时；
. 当函数中包括 UUID() 时；
. 2 个及以上包括 AUTO_INCREMENT 字段的表被更新时；
. 执行 INSERT DELAYED 语句时；
. 用 UDF 时；
. 视图中必需要求运用 row 时，譬喻成立视图时利用了 UUID() 函数；
设定主从复制模式：
1
2
3
4
log-bin=mysql-bin
binlog_format=”MIXED”
也可以在运行时动态修改 binlog 的名目。譬喻：
1
2
3
4
5
6
mysql> SET SESSION binlog_format = ‘STATEMENT’;
mysql> SET SESSION binlog_format = ‘ROW’;
mysql> SET SESSION binlog_format = ‘MIXED’;
mysql> SET GLOBAL binlog_format = ‘STATEMENT’;
mysql> SET GLOBAL binlog_format = ‘ROW’;
mysql> SET GLOBAL binlog_format = ‘MIXED’;
两种模式的比拟：
Statement 利益
汗青悠久，技能成熟；
发生的 binlog 文件较小；
binlog 中包括了所有数据库修改信息，可以据此来审核数据库的安详等环境；
binlog 可以用于及时的还原，而不只仅用于复制；
主从版本可以纷歧样，从处事器版本可以比主处事器版本高；
Statement 缺点：
不是所有的 UPDATE 语句都能被复制，尤其是包括不确定操纵的时候；
挪用具有不确定因素的 UDF 时复制也大概呈现问题；
运用以下函数的语句也不能被复制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非启动时启用了 –sysdate-is-now 选项)
INSERT … SELECT 会发生比 RBR 更多的行级锁；
复制必要执行全表扫描 (WHERE 语句中没有运用到索引) 的 UPDATE 时，必要比 row 请求更多的行级锁；
对付有 AUTO_INCREMENT 字段的 InnoDB 表而言，INSERT 语句会阻塞其他 INSERT 语句；
对付一些巨大的语句，在从处事器上的耗资源环境会更严重，而 row 模式下，只会对谁人产生变革的记录发生影响；
存储函数(不是存储流程 )在被挪用的同时也会执行一次 NOW() 函数，这个可以说是坏事也大概是功德；
确定了的 UDF 也必要在从处事器上执行；
数据表必需险些和主处事器保持一致才行，不然大概会导致复制堕落；
执行巨大语句假如堕落的话，会耗损更多资源；
Row 利益
任何环境都可以被复制，这对复制来说是最安详靠得住的；
和其他大大都数据库系统的复制技术一样；
大都环境下，从处事器上的表假如有主键的话，复制就会快了许多；
复制以下几种语句时的行锁更少：
* INSERT … SELECT
* 包括 AUTO_INCREMENT 字段的 INSERT
* 没有附带条件可能并没有修改许多记录的 UPDATE 或 DELETE 语句
执行 INSERT，UPDATE，DELETE 语句时锁更少；
从处事器上回收多线程来执行复制成为大概；
Row 缺点
生成的 binlog 日志体积大了许多；
巨大的回滚时 binlog 中会包括大量的数据；
主处事器上执行 UPDATE 语句时，所有产生变革的记录城市写到 binlog 中，而 statement 只会写一次，这会导致频繁产生 binlog 的写并发请求；
UDF 发生的大 BLOB 值会导致复制变慢；
不能从 binlog 中看到都复制了写什么语句(加密过的)；
当在非事务表上执行一段会萃的 SQL 语句时，最好回收 statement 模式，不然很容易导致主从处事器的数据纷歧致环境产生；
别的，针对系统库 MySQL 内里的表产生变革时的处理惩罚准则如下：
假如是回收 INSERT，UPDATE，DELETE 直接操纵表的环境，则日志名目按照 binlog_format 的设定而记录；
假如是回收 GRANT，REVOKE，SET PASSWORD 等打点语句来做的话，那么无论如何都要利用 statement 模式记录；
利用 statement 模式后，能处理惩罚许多原先呈现的主键反复问题；