u RC与 MIXED配置组合
事务安全性：结合InnoDB提供的MVCC功能，可以做到只看见已经提交事务修改后的数据，但是无法确保同一事务内，同一个查询语句二次执行，
获得的记录集相同；
事务性能：会比不提交读隔离级别性能低，但比可重复读隔离级别性能高；
日志记录格式：所有的变更操作都以基于行模式登记二进制日志(简称：LBR)；
复制安全性：能做到主备数据复制的一致性；
IO量：所有的DML操作都将转化成基于行模式登记二进制日志，那么会增加大量物理写IO；
u RC与 ROW配置组合
若是事务隔离级别设置为：Read-committed(以下简称：RC)，那么无论日志模式(注：binlog_format)设置为：MIXED 或者 ROW，二进制日志都将以ROW模式登记，为此与RC+MIXED配置组合相同，不赘述。
n 事务隔离级别为：Repeatable-read(简称：RR)
事务安全性：在RC隔离级别优点的基础之上，做到了同一个事务内，同一个查询请求，多次执行，获得的记录集一定相同；
事务性能：比RC事务隔离级别消耗的资源更多一些，也即性能低一些，但比
Seriailizable隔离级别的性能好；
u RR与 STATEMENT配置组合
日志记录格式：基于命令行模式登记二进制日志(简称：LBS)；
复制安全性：对于SQL语句中，若存在不确定性的函数，则数据复制存在一致性；
IO量：无增加；
u RR与 MIXED配置组合
日志记录格式：对于SQL语句中无不确定性函数的DML操作，则会基于命令行模式登记二
进制日志(简称：LBS)；但是对于包含不确定性函数的DML操作，则一定
会使用基于行模式登记二进制日志(简称：LBR)
复制安全性：能确保数据复制的正确性；
IO量：相比STATEMENT可能会增加，但是否增加二进制的量，主要看编写的SQL语句，是否包含一些不确定性的函数；
u RR与 ROW配置组合
日志记录格式：对于所有的DML操作，都采用基于行的模式登记二进制日志，；
复制安全性：能确保数据复制的正确性；
IO量：全采用基于行的模式登记二进制日志，将明显增加物理IO；
事务隔离级别和日志模式组合适用的场景阐述：
u RC与 STATEMENT配置组合
结合上述的分析和总结，提交读+基于命令行模式。首先是跑事务引擎的MySQLd服务，不支持此组合模式，那么其适合场景：
1>.使用非事务引擎存储数据、支撑业务，不使用事务引擎 (一般指：InnoDB引擎)；
2>.不需要使用到mysql复制的架构，或者SQL语句确定不包含不确定性函数等内容；
u RC与 MIXED配置组合
1>.允许事务中，存在同一个SQL查询语句多次执行获得的记录集不同，或者规避此类业务；
2>.读操作量远远大于写操作的业务场景；
3>.不需要打开二进制日志功能的业务场景；
u RC与 ROW配置组合
对于事务隔离级别：RC，无论binlog_format设置为：MIXED 还是 ROW，其二进制日志登记模式都一样，所以其适合场景与RC与 MIXED配置组合一样。
u RR与 STATEMENT配置组合
1>.需要确保事务中，同一个SQL查询语句多次执行获得的记录集相同的业务场景；
2>.不需要关心读写比例的业务场景；
3>.不使用mysql的复制功能，或者DML操作SQL确保不存在不确定性的内容；
u RR与 MIXED配置组合
1>.需要确保事务中，同一个SQL查询语句多次执行获得的记录集相同的业务场景；
2>.需要使用mysql的复制功能，且不想关心 DML操作类SQL语句是否存在不确定性的内容；
3>.更新操作量还是比较多，且想减少登记二进制日志而增加的物理IO，以及加速mysql复制的速度；
u RR与 ROW配置组合
1>.需要确保事务中，同一个SQL查询语句多次执行获得的记录集相同的业务场景；
2>.需要使用mysql的复制功能，且不想关心 DML操作类SQL语句是否存在不确定性的内容；
3>.以读为主的业务，更新量较少且从设计上规避行模式登记日志缺陷的业务场景；
