MySQL 默认的事务隔离级别是什么为什么选择这个级别MySQL InnoDB默认事务隔离级别是 RR可重复读 Repeatable Read为什么MySQL默认选用RR而不是RC防止主从复制出现数据不一致历史核心原因早期MySQL版本binlog只支持statement格式。statement格式记录原始SQL语句主库RC隔离级别下如果事务执行顺序不同从库回放SQL执行结果和主库不一致造成主从数据错乱。RR隔离级别可以规避这个statement模式下的主从同步bug。现在有row格式binlog可以解决该问题但历史原因保留RR作为默认。保证同一个事务内部数据快照一致性RR级别下整个事务看到的是统一数据快照事务内部多次查询结果保持不变不会受到其他事务提交修改的干扰不会出现不可重复读。业务中很多场景同一个事务多次查询同一份数据希望前后读取结果一致RC会出现前后读取不一样的现象。InnoDB在RR下解决了幻读问题SQL标准里RR是会存在幻读的但是InnoDB通过MVCC多版本控制 临键锁(Next‑Key Lock)在RR隔离级别解决了幻读。相当于在这个隔离级别既拿到不错的隔离效果又不用直接上串行化牺牲大量并发性能。平衡一致性与并发性能比RC隔离级别更高的数据一致性对比Serializable串行化不会完全锁死并发性能远好于串行化做到一致性和性能折中。补充互联网业务为什么很多会改成RCRC读已提交也有优势RC没有间隙锁只有行锁锁范围更小锁冲突变少并发更高避免RR下间隙锁带来的死锁问题现在线上binlog普遍使用row行格式不再有早期statement主从不一致的问题所以很多公司业务主动修改为RC。总结MySQL InnoDB默认隔离级别是可重复读RR。最初主要为了解决statement格式binlog主从复制不一致同时事务内多次查询数据保持一致并且InnoDB通过MVCC临键锁解决幻读在一致性和并发之间做了很好平衡。现在很多互联网项目会主动调整为RC获取更高并发。 MySQL 默认的事务隔离级别是什么为什么选择这个级别MySQL InnoDB默认事务隔离级别是 RR可重复读 Repeatable Read为什么MySQL默认选用RR而不是RC防止主从复制出现数据不一致历史核心原因早期MySQL版本binlog只支持statement格式。statement格式记录原始SQL语句主库RC隔离级别下如果事务执行顺序不同从库回放SQL执行结果和主库不一致造成主从数据错乱。RR隔离级别可以规避这个statement模式下的主从同步bug。现在有row格式binlog可以解决该问题但历史原因保留RR作为默认。保证同一个事务内部数据快照一致性RR级别下整个事务看到的是统一数据快照事务内部多次查询结果保持不变不会受到其他事务提交修改的干扰不会出现不可重复读。业务中很多场景同一个事务多次查询同一份数据希望前后读取结果一致RC会出现前后读取不一样的现象。InnoDB在RR下解决了幻读问题SQL标准里RR是会存在幻读的但是InnoDB通过MVCC多版本控制 临键锁(Next‑Key Lock)在RR隔离级别解决了幻读。相当于在这个隔离级别既拿到不错的隔离效果又不用直接上串行化牺牲大量并发性能。平衡一致性与并发性能比RC隔离级别更高的数据一致性对比Serializable串行化不会完全锁死并发性能远好于串行化做到一致性和性能折中。补充互联网业务为什么很多会改成RCRC读已提交也有优势RC没有间隙锁只有行锁锁范围更小锁冲突变少并发更高避免RR下间隙锁带来的死锁问题现在线上binlog普遍使用row行格式不再有早期statement主从不一致的问题所以很多公司业务主动修改为RC。总结MySQL InnoDB默认隔离级别是可重复读RR。最初主要为了解决statement格式binlog主从复制不一致同时事务内多次查询数据保持一致并且InnoDB通过MVCC临键锁解决幻读在一致性和并发之间做了很好平衡。现在很多互联网项目会主动调整为RC获取更高并发。 
