mysql 5.6 binlog_format_MySQL 5.6 binlog_format 和 transaction_isolation 组合产生的效果及分析...

YES 代表支持binlog_format+transaction_isolation组合NO 代表不支持binlog_format+transaction_isolation组合

(以

1. STATEMENT + READ UNCOMMITTED

INSERT、UPDATE、DELETE语句无法写入二进制日志中，进而导致主库上无法执行该类型语句。

2. STATEMENT + READ COMMITED

INSERT、UPDATE、DELETE语句无法写入二进制日志中，进而导致主库上无法执行该类型语句。

解释原因：在READ COMMITTED、READ UNCOMMITED事务隔离级别下，基于binlog_format=’STATEMENT’模式下，SQL语句记录的顺序会导致主从

以READ COMMITED为例，假设STATEMENT模式下能写入二进制日志中。

分析：

如上，在主库上执行一次如上操作，二进制日志记录SQL语句的方式为commit之后写入二进制日志中。

故记录二进制日志的顺序为SESSION 2 , SESSION 1

此时如果有从库，那么从库执行的结果为：

s

delete from t1 where c1 = 2;

select * from t1;

+——+——+

| c1 | c2 |

+——+——+

| 1 | 1 |

| 1 | 1 |

+——+——+

commit;

start transaction;

select * from t2;

+——+——+

| c1 | c2 |

+——+——+

| 1 | 3 |

| 2 | 2 |

| 1 | 3 |

| 2 | 2 |

+——+——+

update t2 set c2 = 4 where c1 in (select c1 from t1);

select * from t2;

+——+——+

| c1 | c2 |

+——+——+

| 1 | 4 |

| 2 | 2 |

| 1 | 4 |

| 2 | 2 |

+——+——+

commit;

此时对比主库与从库的t2表：

由此可见数据不一致现象，read uncommitted+statement同理可得。

使用binlog_foemat=row/mixed

使用repeatable read 或 serializable事务隔离级别

关闭将语句记录到二进制日志的功能，set session

注：

REPEATABLE READ + MIXED SERIALIZABLE + MIXED

INSERT、UPDATE、DELETE是以STATEMENT写入二进制日志中

READ UNCOMMITTED + MIXED READ COMMITTED + MIXEDINSERT、UPDATE、DELETE是以ROW写入二进制日志中