通过阅读翻译后的二进制日志详细内容，以及对比不同事务隔离级别和binlog_format配置组合情况下，登记的二进制日志， 我们可以分析、总结出如下内容：
● 二进制日志文件中，表结构中字段名成都是用@符号，加数字编号的模式，且是按字段先后顺序编号的方式，此地方就是一个风险点，尤其双主复制模式下，后续篇章讲解复制存在的风险点详细告诉大家;
● RC模式下对事务引擎：InnoDB是全部采用行模式记录二进制日志;
● 行模式登记二进制日志时，字段的原内容是全部出现在：WHERE部分，需要被修改后的内容全部显示在：SET部分，为此若表字段多或有大字段，对数据做变更之时，产生的二进制日志内容将会很大，从而消耗大量系统的物理IO资源;
● 行模式登记二进制日志时，对于字段值更新的SQL中不确定性的内容，将会替换为确定性的值登记到二进制日志文件中;
● 行模式登记二进制日志时，若DML操作SQL语句，使用了范围条件，而登记到二进制日志中的内容，是实际更新的条数详细内容，此模式也会增加大量二进制日志的容量;
● 行模式登记二进制日志时，若是表有大字段或者某个表字段很多，那么产生的二进制日志容量就会非常大了，意味着消耗系统的物理IO资源将会急剧增加;
● Binlog_format设置为：MIXED,对于二进制日志以基于命令行模式 还是 基于行模式登记，取决于：事务隔离级别和所涉及的SQL共同决定，但是对于RC事务隔离级别，就无论什么类型的DML操作SQL，都以行模式登记;
● 事务隔离级别为：RC情况下，binlog_format设置为MIXED还是为ROW，对于二进制日志登记而言都是一样的，以行模式登记二进制日志。
● 事务隔离级别为：RR情况下，binlog_format设置为MIXED，mysqld服务会根据DML操作的SQL语句情况，决定是以行模式登记二进制日志，还是以 命令行模式登记;
● 事务隔离级别为：RR情况下，binlog_format设置为MIXED，mysqld服务会添加类似Oracle的hint内容，解决部分不确定性函数而带来的SQL重复执行无法获得相同记录值的问题;
后续：
上述为事务隔离级别+binlog_format组合模式下，不同的二进制日志登记模式，通过分析、比对了各自的优缺点，以及给出了大家什么类型业务场景下的组合配置模式，希望帮助掌握这块的知识点，以及能帮助大家针对自己的业务场景，可以作出正确的事务隔离级别+binlog_format配置组合选择。
另外，对于mysql基于三种不同复制模式情况下，登记的二进制日志的二种模式，以及基于表：是否有主键(或非空唯一索引)、是否有索引等组合在一起，二进制日志在登记、复制过程中应用二进制日志，其效果都是不一样的，也并不像大家想的那样，为此，后续会专门写一篇文章与大家分享、探讨。
