mysql binlog之二 三种格式的分析对比

基础材料：

centos7.5  mysql 5.7.24  开启GTID

---

binlog对于mysql是至关重要的，binlog与undo redo一起保证了数据的完整性，用于数据恢复，崩溃恢复、任一时间点恢复、甚至是任意一条数据的恢复。所有的高可用模式也都是基于binlog进行处理的。

本文主要对binlog的三种存储格式statement、row、mixed进行分析对比其优缺点。

---

statement格式：

在statement格式下，binlog忠实的记录的执行过的语句，你执行过什么语句它就照搬复制到binlog中。由于其可能造成主从不一致的情况，所以生产环境基本都不会设置为statement。

优势：1、节省空间。由于只是对执行的语句进行记录，所以相比row模式binlog所占的空间很小

           2、提高数据库性能。由于binlog是在事务提交时才进行fsync刷盘操作，而刷盘的操作是最耗费IO的，statement只需要记录一条语句而不是记录所有操作过的数据行。

劣势：可能造成主从不一致

在测试环境执行delete from test limit 10;删除表中的10条数据，观察binlog的内容变化，binlog部分内容如下：

可以看到执行过的语句被原原本本的记录到binlog中，被同步到从库重做。

执行delete from test limit 10;时还会产生一个警告，大意就是使用statement格式时执行limit语句可能造成主从同步不一致。因为limit语句只是指定了删除10条记录，但没有指定具体是哪10条，当mysql在两次执行时选择了不同的索引进行操作时，删除的记录就是不同的。当然还有其他函数也可能会造成主从不一致。

---

 row格式：

在row格式下，binlog对于DDL操作记录执行的SQL语句，对于DML语句则记录具体操作的数据行。一般生产环境采用该格式。

优势：对于DML操作记录了具体的行数据，保证重放的一致性，同时也可以对一些误操作的数据进行单独恢复提供了可能性

劣势：由于记录了每条数据的内容变更，导致了binlog日志占用了很大的空间，由于fsync时一次写入数据过多，在一定程度上影响了性能。

调整binlog格式为row，执行delete from testxxxx limit 10;观察binlog的内容变化，binlog部分内容如下：

可见binlog修改的每一行数据的具体值都被记录了下来。如果我需要恢复其中的某一条记录只要把delete转换成insert就可以了，这是其他格式做不到的。

---

mixed格式：

集前两种格式的优点，对于DDL只对SQL语句进行记录。对DML操作则会进行判断，如果mysql判断会造成主从不一致，就会采用row格式记录，反之则用statement格式记录。

优点：节省空间，提高数据库性能，通过判断保证数据重放时的一致性。

缺点：无法对误操作数据进行单独恢复

调整binlog格式为mixed，执行delete from test  limit 1;和delete from test where a =1;观察binlog的内容变化，binlog部分内容如下：

可见对于limit语句可能造成主从不一致的情况下，mysql选择了row格式进行记录，对于后面执行delete语句则采用了statement格式进行记录。

---