MySQL 为什么默认是 RR 而不是 RC？隔离级别选型真相-北京尧图网络

先给结论MySQL 默认选可重复读RR直接原因是历史包袱早期主从复制用的是 statement 格式的 binlog在 RC 下会产生主从数据不一致。RR 的间隙锁堵住了这个口子。而 RR 下的幻读是基本解决不是彻底解决。快照读靠 MVCC当前读靠 next-key lock两套机制各有适用范围边界处仍然能复现出问题。一个经常被误判的线上现象一个典型的场景是这样的对账任务在一个事务里跑中途业务库还在写入。任务前后两次读到的数据对不上开发怀疑数据库有问题第一反应是把隔离级别提到串行化。提到串行化之后数据是对了但整个库的事务吞吐掉得很厉害因为所有普通SELECT会被隐式加上共享锁。真正的解法往往不是提级而是想清楚这件事任务到底需不需要一个跨多张表的一致性快照。需要的话RR 下一次普通读就够了因为它从头到尾复用同一个 ReadView本来就是一致的。不需要的话拆成几个小事务用 RC 并发度还更高。把隔离级别当成安全等级来调是最常见的误用。它是并发度和一致性的取舍旋钮不是安全开关。先把四个级别和三个问题列清楚SQL 标准定义了三种并发问题脏读读到了别人没提交的数据不可重复读同一个事务里两次读同一行值不一样幻读同一个事务里两次按条件查行数不一样多出来的行是别人新插的。级别脏读不可重复读幻读读未提交有有有读已提交 RC无有有可重复读 RR无无基本解决串行化无无无注意第三行那个基本解决。这个措辞不是偷懒是事实下面第 4 节会讲清楚差在哪。顺带说一句RC 和 RR 都靠 MVCC 实现唯一差别是 ReadView 的生成时机RC 每条快照读都生成新的RR 只在事务第一条快照读时生成。这一条在 J005 里完整展开过这里不重复。RR 胜出的真正原因关键在 binlog 的格式binlog 有三种格式statement 记录原始 SQLrow 记录每一行的前后变化mixed 是两者混用。早期 MySQL 默认用 statement。它有个特点binlog 里记录的顺序是事务提交的顺序不是 SQL 执行开始的顺序。而在 RC 下写操作不加间隙锁只锁住命中的行。这两件事撞到一起就出事了。一个能复现的不一致构造一张表-- MySQL 8.0构造用 CREATE TABLE t ( id INT PRIMARY KEY, c INT ) ENGINEInnoDB; INSERT INTO t VALUES (1,1),(2,2),(3,3),(4,4);把隔离级别设成 RCbinlog 设成 statement然后按这个顺序开两个会话-- 会话 1 BEGIN; DELETE FROM t WHERE id 3; -- 锁住已存在的 id4不加间隙锁 -- 会话 2 BEGIN; INSERT INTO t VALUES (5,5); -- 不被阻塞插入成功 COMMIT; -- 先提交 -- 会话 1 COMMIT; -- 后提交主库上会话 1 执行 DELETE 的时候 id5 还没插入所以它只删掉了 id4。主库最终保留 id5。再看从库。binlog 按提交顺序记录会话 2 先提交于是 binlog 的顺序是INSERT INTO t VALUES (5,5); DELETE FROM t WHERE id 3;从库回放先插入 id5再删 id 大于 3 的行。结果 id5 被删掉了。从库没有 id5。一边的行还在另一边的行没了。RR 怎么堵住这个口子把隔离级别换成 RR会话 1 的DELETE ... WHERE id 3会加 next-key lock锁住(3, ∞)这个区间。会话 2 的插入会被阻塞一直等到会话 1 提交才能继续。锁住了两个事务的提交顺序就被强制成串行binlog 里的执行顺序和主库上的逻辑顺序一致主从也就一致了。所以 RR 胜出不是因为它更安全是它顺手修了复制链路上的这个洞。那现在还需要 RR 吗这个洞只在 statement 格式下存在。row 格式记录的是每一行的实际变化回放精确不存在这个顺序问题。MySQL 从 5.7.7 开始binlog_format的默认值已经改成了 ROW。这也是为什么现在很多团队把默认隔离级别改成 RC而且跑得很稳。前提要讲清楚改 RC 之前先确认你的 binlog 是 row 格式。还在用 statement 的话上面那个不一致照样会发生。RR 的代价RR 不是白给的。间隙锁锁的是区间比 RC 下只锁命中行大一圈带来的直接后果有两个一是并发度低。本来不冲突的插入可能被挡住。二是死锁变多。间隙锁之间也会互相等待两个事务交叉插入同一区间时很容易形成环。我见过不少线上死锁日志根因就是 RR 下的间隙锁换成 RC 之后直接消失。所以选型的真实权衡是RC 拿到更高的并发和更少的死锁代价是同一个事务里前后读可能不一致RR 拿到跨语句的一致性视图代价是锁范围和死锁概率。面试官在等的那句答完四个级别和三种问题只是及格。真正让人抬眼的是接上这一段严格说RR 下幻读是基本解决不是彻底解决。快照读的幻读靠 MVCCReadView 从头到尾没变别人新插入的行对你不可见。但当前读必须读最新数据SELECT ... FOR UPDATE和UPDATE靠的是 next-key lock。边界在这里如果一个事务先做普通 SELECT后面又做了当前读两次结果仍然可能对不上。这是可以复现的所以我认为RR 解决了幻读这个说法在严格意义上是错的只能说基本解决。为什么这句话值钱因为它说明你知道 MVCC 的能力边界在哪。绝大多数人只会背RR 解决幻读答到这里就停了。想再加一层可以补一句RR 下幻读的两条防线分别属于两套机制MVCC 管读、间隙锁管写把这两件事分开讲清楚的人不多。四个常见误区误区一以为隔离级别越高越安全它是取舍旋钮不是安全开关。串行化把普通 SELECT 都加上共享锁吞吐掉得非常厉害生产上极少用。误区二以为 RR 下完全没有幻读上面已经说清楚了。先快照读再当前读仍然能复现。误区三以为间隙锁只在 RR 下有基本正确间隙锁是 RR 引入的RC 下只有行锁这也是 RC 并发更高的原因之一。但外键约束检查和唯一键冲突场景下RC 也会有特殊的间隙锁行为具体看版本。误区四看到主从不一致就先怀疑网络先把 binlog 格式和隔离级别看一遍。这两项的组合能解释相当一部分莫名其妙的不一致。速查表场景选哪个前提与代价默认不动RR锁范围大死锁偏多高并发写入、binlog 是 rowRC同一事务内前后读可能不一致需要跨多表一致性快照RR一次普通读即可不必上串行化还在用 statement 格式 binlog别改 RC会复现主从不一致死锁日志里全是间隙锁考虑 RC先确认业务能接受不可重复读一个还没聊完的问题混合格式的 binlog 在这件事上是个折中但它什么时候切到 statement、什么时候切到 row判断逻辑并不总是符合直觉出问题时排查反而更麻烦。你们线上的 binlog 用的是哪种格式有没有因为格式和隔离级别的组合踩过坑评论区聊聊。另外完整的十二个模块Java / C / Go / JVM / MySQL / Redis / MQ / 分布式 / 事务 / 网络 / 系统设计 / 项目深挖我整理成了一份手册每题都标了考察点和加分答法。【草丛后端架构】持续分享后端架构与底层原理。

MySQL 为什么默认是 RR 而不是 RC？隔离级别选型真相

相关推荐

先更新数据库还是先删缓存？八种方案里错的有几种

Python 的哈希契约：为什么 list 不能当字典的键

最小操作次数使数组元素相等 III【力扣LeetCode 每日一题】

更多资讯

GitHub仓库如何助力大模型学习与工程实践

Sobol全局灵敏度分析MATLAB实现：方差分解与采样估计

Delta机器人正逆解：从几何约束到MATLAB实现与避坑

Docker Compose 下载与更新全攻略：在线镜像加速与离线安装指南

幽默化设计：让家务变娱乐的5大策略

技术人如何培养产品思维：从实现到洞察的转型

今日更新

多智能体协作系统架构设计与实践优化

大模型系统性入门实战指南：从原理到部署微调的全链路路线

鸿蒙文件系统沙箱机制解析与开发实践

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？