干了十几年后端数据库相关的坑没少踩尤其是MySQL的事务隔离级别和MVCC这块。面试的时候能把这俩概念背得滚瓜烂熟的人不少可真到了线上出问题能不看文档、不看报错堆栈直接定位到根因的就没那么多了。我自己的体会是这块知识属于典型的“你以为你懂了其实一深挖就露馅”的领域。这篇文章不聊虚的我就以实战为出发点把MySQL的事务隔离级别到底隔离了什么、MVCC在底层是怎么运作的、以及我们在日常开发和运维中怎么利用好这些机制原原本本拆开讲清楚。无论是刚接触数据库开发的新手还是已经在写复杂业务逻辑的资深工程师甚至是要处理线上疑难杂症的DBA这篇文章都能给你提供一套可以直接用的排查思路和优化手段。保证你看完再去调事务、看死锁心里是有底的。1. 事务隔离级别教科书上的概念生产环境里的真问题聊MVCC之前必须先把事务隔离级别这层窗户纸捅破。很多刚入门的朋友对这四种级别读未提交、读已提交、可重复读、串行化的理解停留在背定义的层面这远远不够。我们要搞清楚的不是“谁允许谁不允许”而是“为什么需要隔离”以及“隔离的代价是什么”。1.1 隔离级别到底在防什么咱们先回到最原始的场景数据库里有条数据两个事务同时去读写它会发生什么理论上就会出现三类问题脏读、不可重复读、幻读。脏读事务A读到了事务B未提交的数据。如果事务B回滚了事务A读到的就是个不存在的脏数据。最典型的就是你查余额看到一个数字准备下单结果对方回滚了你按这个数字做决策就得出事。不可重复读事务A在同一个事务里两次执行同一条SELECT读到的数据不一样。原因是事务B在这期间修改了数据并且提交了。这个问题的本质是“同一行数据前后不一致”。幻读事务A在同一个事务里两次执行同一条范围查询比如WHERE id 100结果第二次多出了几行。原因是事务B在这期间插入了新数据并提交。这个问题的本质是“结果集的行数前后不一致”。你可能觉得这看着不都一样吗不行这俩必须分清楚。不可重复读是“行内容”变了幻读是“行集合”变了。解决它们的手段也完全不同一个靠锁住行一个得锁住范围。1.2 四种隔离级别的一次说清基于上面三种异常SQL标准定义了四个隔离级别MySQL的InnoDB引擎都实现了。我直接用一张表给你讲明白每一档到底做了什么、防了什么隔离级别脏读不可重复读幻读实现原理概括读未提交 READ UNCOMMITTED可能发生可能发生可能发生读数据不加锁直接读最新版本基本没啥隔离性读已提交 READ COMMITTED不会发生可能发生可能发生每次读都生成一个新的ReadView只能看到已提交的数据可重复读 REPEATABLE READ不会发生不会发生基本不会InnoDB特殊处理事务第一次读时生成ReadView整个事务内复用串行化 SERIALIZABLE全部避免全部避免全部避免用的全是锁读写互相阻塞并发度最差逐条说明。读未提交在生产环境里基本没人用性能是快但你会读到别人没提交的“半成品”数据业务上完全没法接受。读已提交是很多其他数据库比如Oracle、PostgreSQL的默认级别。它的好处是每次SELECT都是最新快照缺点就是在一个事务里多次读同一行可能读到不同的值这就是不可重复读。可重复读是MySQL的默认隔离级别。它保证了你的事务一开始读到什么到结束前读到的永远是这个一致的快照感觉就像给数据库拍了一张照片。至于幻读理论上InnoDB应该在可重复读下也防不住但它愣是通过锁机制把这块也给堵上了这点后文详细说。串行化是最严格的它直接让读写互相等待能完全避免所有异常但代价就是性能断崖式下跌。没有极其特殊的需求别碰它。1.3 MySQL默认级别的选择逻辑为什么MySQL要选可重复读作为默认有个广泛流传的说法是MySQL确切说是InnoDB从诞生起就支持复制主从同步而早期在主从架构里MySQL的复制是基于记录二进制日志binlog来同步的只有可重复读这个隔离级别配合特定的日志格式才能保证从库重放日志时不会出现数据不一致。虽然这个说法随着版本迭代已经不那么绝对了但历史包袱确实存在这么多年来默认值也一直没改。另外一个现实原因是可重复读搭配MVCC机制在大部分业务场景下读操作根本不加锁能提供非常高的并发读性能。对于以读为主、写为辅的典型互联网应用来说这就是最舒服的模式。不过这里要提醒一句别觉得默认就是最好的。如果你做的业务对实时性要求极高比如你看一个合作方的报价对方改了你希望立刻就看到那么可重复读反而会坑你因为你的快照一旦建立整个事务内都看不到别人后来的提交。这时候就得评估一下是改成读已提交还是把事务拆短。这是后话我们先把底层原理吃透。2. MVCC底层机制版本链和ReadView的完整解读MVCCMulti-Version Concurrency Control多版本并发控制听起来高大上说白了就是数据库里的一行数据在物理上可能存在多个版本也就是多个副本。不同的事务根据自己启动时看到的情况决定去读哪个版本。这样读的人不用等写的人写的人也不用等读的人并发能力自然就上来了。但这里有个核心问题数据库怎么知道该给哪个事务展示哪个版本这就引出了MVCC的两大支柱——undo log版本链和ReadView判断规则。2.1 数据行里的隐藏列版本的锚点InnoDB的每行记录除了我们建表时自定义的字段还有几个隐藏的数据库字段它们才是MVCC能跑起来的基础DB_TRX_ID最近一次修改这行数据的事务ID。注意是“最近一次”而且只记录修改INSERT/UPDATE/DELETE它的事务ID。DB_ROLL_PTR回滚指针指向上一个版本的数据在undo log里的位置。DB_ROW_ID如果表没有显式定义主键InnoDB会自动生成一个隐藏主键。这里面DB_TRX_ID和DB_ROLL_PTR就是两个最关键的东西。你想想事务ID是我们判断“当前事务”和“操作这个版本的事务”之间先后顺序的凭证回滚指针则串起了一条历史版本项链。2.2 undo log与版本链undo log直译是回滚日志。它的基本作用是事务回滚时把数据恢复到修改前的样子。但另一个极其重要的功能就是为MVCC提供历史版本数据。当一行数据被修改时InnoDB会把修改前的旧值连同事务ID写入undo log然后更新这行数据的DB_ROLL_PTR让它指向刚写入的undo log记录。这样这一行最新值通过回滚指针就连接到了它的旧值旧值又连接到更旧的值一条数据的所有历史版本就形成了一条链表。我做一个简单的比喻这就像一部电影的剪辑版本正片是当前最新的一帧画面而旁边堆着一摞前任剪辑版本的胶片每盘胶片上都标注了“这一版是谁、在哪天剪的”想看旧版本顺着胶片上的标注往回找就行。当越来越多的事务来修改同一行的时候这条版本链会越来越长。长版本链本身不会造成数据错误但会有副作用读操作虽然不需要加锁但沿着版本链找到正确版本的过程需要遍历如果版本链太长这个过程就会变慢。所以不要让热点数据频繁被更新这在某些极端场景下会是性能隐患。2.3 ReadView判断版本的“准入名单”版本链有了但事务读数据的时候不能全链都认。它需要一套规则来判断哪些历史版本是“我”可见的哪些是“我”不能看的。这套规则就封装在一个叫ReadView读视图的结构里。具体来说ReadView里存了四个关键信息我直接给你列出来creator_trx_id创建这个ReadView的事务的ID。m_ids在创建ReadView时当前系统中所有“活跃”的事务ID列表。这里说的活跃是指已经启动、但还没提交的事务。min_trx_idm_ids列表中最小的那个事务ID。max_trx_idm_ids列表中最大的事务ID加1。说白了就是“下一个将要生成的事务ID”的边界。这里送大家一个简单的判断逻辑当一个版本链里某个版本的DB_TRX_ID被拿出来和ReadView比对时分这么几种情况情况判断结论DB_TRX_ID min_trx_id这个版本是在ReadView创建之前就提交的可见DB_TRX_ID max_trx_id这个版本是在ReadView创建之后才生成的不可见min_trx_id DB_TRX_ID max_trx_id需要查m_ids列表若在m_ids里说明事务还没提交不可见若不在m_ids里说明事务已提交可见DB_TRX_ID creator_trx_id这个版本就是自己这个事务改的可见上面这个规则就是MVCC判断版本可见性的“核心算法”。上面这些逻辑如果你理解了那你自然就能明白读已提交和可重复读本质上的区别就一句话——ReadView的生成时机不一样。2.4 快照读与当前读MVCC世界的两套读法我前面讲了半天MVCC都是针对“快照读”的。但MySQL里还有一种读叫“当前读”。这俩要是搞混了你会摔跟头。快照读就是普通的SELECT语句在可重复读隔离级别下它读取的是事务开始时的那个快照也就是ReadView决定了的一个历史版本不加任何锁所以读操作永远不会阻塞写操作。这是MVCC最闪耀的优点。当前读包括SELECT ... LOCK IN SHARE MODE、SELECT ... FOR UPDATE、UPDATE、DELETE。这类操作读的是数据的最新版本并且需要加锁。因为它们要修改数据必须先拿到最新的、准确的数据再说不然改了就是错改。你发现了吧锁和MVCC不是割裂的它们是一对组合拳。MVCC让普通的读变得无锁高效而锁机制则保证了当前读的数据准确性和并发安全性。在实际业务里一个复杂的事务往往是先有若干快照读做计算和校验最后用一个UPDATE做修改触发当前读这两种读法会同时被用到。3. 隔离级别下的行为验证亲手跑一遍比看十遍文档管用理论扯再多不如自己动手跑一遍。这一节我们来搭一个最小实验环境亲自验证一下可重复读和读已提交下MVCC到底是怎么表现不同的。3.1 实验环境搭建与基础数据我用的环境是MySQL 8.0其实5.7及以上版本行为差异不大都能复现。先建一张简单的用户余额表CREATE DATABASE IF NOT EXISTS test_mvcc; USE test_mvcc; CREATE TABLE account ( id INT PRIMARY KEY AUTO_INCREMENT, user_name VARCHAR(50) NOT NULL, balance DECIMAL(10, 2) NOT NULL ) ENGINEInnoDB; INSERT INTO account (user_name, balance) VALUES (Alice, 100.00);然后打开两个MySQL客户端窗口分别代表两个不同的事务。我们叫它会话A和会话B。为了测试方便我把autocommit关掉并手动控制事务边界。操作前先确认一下当前的隔离级别mysql SELECT transaction_isolation; ------------------------- | transaction_isolation | ------------------------- | REPEATABLE-READ | -------------------------3.2 实验场景一可重复读下的快照隔离这个实验我设计成事务A先启动并查询一次数据事务B随后修改并提交数据然后事务A再查询一次看看会发生什么。会话A事务1-- 开启事务 START TRANSACTION; -- 第一次查询 SELECT balance FROM account WHERE id 1;此时A读到的balance是100.00。会话B事务2START TRANSACTION; UPDATE account SET balance 200.00 WHERE id 1; COMMIT;B修改并提交了此时数据库里Alice的余额物理上已经是200.00了。回到会话A事务1依然未结束-- 第二次查询 SELECT balance FROM account WHERE id 1;神奇的一幕出现了A第二次读到的依然还是100.00完全无视了B的修改。这个结果乍看有点反直觉但用ReadView解释就非常顺理成章事务A在第一次SELECT时生成了一个ReadView当时的活跃事务列表里可能有事务B也可能没有但关键在于事务A的ReadView一旦生成在可重复读级别下整个事务期间都复用这一个ReadView。所以即使B提交了对A而言B对应的那个事务ID不在A的可见范围内A眼里世界还是它第一次查询时的老样子。记住这个结论可重复读的快照一旦生成整个事务期间都不会变了。这在做报表统计、批量对账时特别有用能保证整个事务里看到的数据是一致连贯的。3.3 实验场景二读已提交下的每次快照刷新现在我们把会话A的隔离级别临时改成读已提交再跑一遍一模一样的操作。-- 会话A执行 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; START TRANSACTION; SELECT balance FROM account WHERE id 1;此时读到的还是100.00。然后让会话B执行和上面完全相同的更新和提交UPDATE account SET balance 300.00 WHERE id 1; COMMIT;回到会话A第二次查询SELECT balance FROM account WHERE id 1;这一回你会看到读到了300.00。同样的一段SQL只因为隔离级别换成了读已提交行为就大变。秘密全在于读已提交下每一次快照读都会生成一个新的ReadView。也就是说每次SELECT的瞬间系统都会重新评估一次哪些事务是活跃的、哪些已经提交了因此B提交之后A新生成的ReadView里自然就看不到B的ID了于是它就读到了B修改后的最新版本。这个差异在实际开发中有个非常值得警惕的点如果某个事务里要多次读取同一份数据并且要求这些读取的结果一致比如发货判断库存、金额核算那么用读已提交就可能因为中途别人提交了修改导致你前后两次读到的值不一样进而导致业务逻辑错乱。这种bug非常难排查因为表面上看着是同一份数据实际背后已经被改过了。3.4 当前读与锁的联动验证接下来验证一下当前读和锁的关系。还是在可重复读隔离级别下。会话A事务1START TRANSACTION; SELECT * FROM account WHERE id 1 FOR UPDATE;此时A拿到了id1这行记录的排他锁。会话B事务2START TRANSACTION; UPDATE account SET balance balance - 50 WHERE id 1;这条UPDATE会一直卡住直到A提交或回滚它才能继续。这充分说明了当前读不只是“读”它在读的同时还在“锁”而且这个锁会把同样想修改这行数据的其他事务阻塞住。这就是为什么有些时候你在数据库上看到某条UPDATE一直在执行但事务就是一直提交不了。多半是前面有一个持锁事务没释放锁。这里也顺带引出一个经验业务代码里的事务凡是涉及更新操作务必保证事务尽可能短促不要在里面做耗时的外部接口调用否则锁持有时间太长会拖垮并发。4. 生产环境里的隐形陷阱排查方向与参数调优理论、实验都有了接下来就是实战环节的重头戏。线上环境不像咱们实验环境这么干净往往伴随着各种并发、复杂的SQL、多种隔离级别混用。这里我把多年积累的排查经验整理成一张速查表和一些优化套路全都是干货。4.1 常见问题的定位思路一览症状可能原因优先排查方向某个事务里两次查询结果不一致用了读已提交隔离级别检查会话或全局的隔离级别设置确认业务对一致性的要求查询结果数量对不上多出或少了行可能存在幻读或并发写入重点看是否用了可重复读、范围查询是否依赖于默认的锁机制UPDATE或DELETE长时间不结束锁等待前面有事务持锁未释放查看performance_schema.data_lock_waits里的阻塞关系应用日志报“Deadlock found”事务死锁拿到死锁日志分析加锁顺序主从复制延迟从库数据不一致大事务、长事务检查是否在事务里执行了过多写入、是否用了不合理的隔离级别看到没大部分坑归根结底都是两个根源要么是隔离级别选错了要么是锁事务时间太长。4.2 一个真实死锁现场的拆解先看一个朋友公司遇到过的案例。业务场景是用户下单扣减两个账户的余额一个是用户余额一个是商家的待结算金额。逻辑很常规事务1里先扣用户余额再增加商家金额事务2里反过来先增加商家金额再扣用户余额。结果某天线上就爆出了一堆死锁。死锁日志用SHOW ENGINE INNODB STATUS\G拿到里通常会显示两条事务各持有一把锁又在等待对方持有的另一把锁。看到这里问题几乎就清楚了两条事务对两个账户的加锁顺序不一致。排查和修复的思路是这样的统一加锁顺序所有事务里对账户的访问必须遵循同一顺序比如按账户ID从小到大排序后依次加锁。只要大家都按照这个规则来就不可能互相等待。缩短持锁时间把事务里无关的查询、外部调用挪到事务外面。只锁该锁的数据锁住之后立刻执行修改并提交。降低死锁影响必要时在代码里捕获死锁异常做重试。MySQL的死锁检测机制会把其中一个事务直接回滚让另一个继续所以应用层见到死锁报错重试一次往往就成功了。这个案例里的核心教训是死锁不是Bug它是并发系统的常态。我们要做的不是幻想它永远不发生而是让业务对“死锁后重试”有容错机制。4.3 和MVCC、隔离级别相关的几个关键参数参数调优不是玄学得有的放矢。和生产环境最相关的有这么几个参数名作用建议innodb_lock_wait_timeout锁等待超时时间默认50秒生产环境可以调小比如5秒让问题快速暴露避免应用长时间卡死transaction-isolation全局隔离级别默认可重复读除非业务明确需要实时性否则不要动autocommit是否自动提交事务在应用连接里务必确认是开启的。这里有个大坑如果你关闭了autocommit又忘了提交事务会一直挂着锁也一直不释放时间久了连接池必然被打满innodb_purge_threads控制undo log清理线程数量undo log积累过多会导致版本链过长影响读性能。调大清理线程数默认4能帮助及时回收autocommit这个参数值得单独拎出来提醒。很多人写代码时喜欢用ORM框架框架默认会开启一个事务包裹住每个操作但如果代码里手动开了事务通常ORM会自动关闭autocommit这时候你要是漏掉了一次commit并且连接又长期空闲那就是妥妥的长事务加持续持锁线上必出事。5. 工程规范怎样设计才能少踩坑技术点聊得差不多我们来聊点工程实践层面的总结和规范。这套规范是从多个项目的血泪史里提炼出来的你直接拿去用就行。5.1 四条事务设计军规按优先级排序这四条就是我的底线事务尽量短。能三步完成的操作不要包十步在里面。事务里的每条语句都会参与锁的管理事务越长锁持有越久别人等待的概率越高。尤其是不要在事务里调用外部HTTP接口、RPC调用这类等待最坑人。用快照读扛住读流量。业务里90%以上的场景读操作用默认的快照读就够。真需要“读到最新值并且要改”再去用当前读。不然就是白白给数据库制造锁竞争。批量任务拆小批量。比如你要更新一万条数据别用一个事务去UPDATE一旦中途出错回滚代价巨大而且这一万行数据会被锁很久。拆成每批几百条分事务提交进度也好追踪。保持加锁顺序一致。涉及多张表、多个行时所有事务必须按同一顺序拜访。这是从根上规避死锁的最朴素、最有效的方法。5.2 当前读和一致性读的混用原则这是我在实际开发里踩过最深的一个坑。曾经遇到一个业务场景需要先“检查余额是否足够”再“扣款”。第一版代码写得想当然-- 两次操作放在同一个事务里 START TRANSACTION; SELECT balance FROM account WHERE id 1; -- 快照读 UPDATE account SET balance balance - 50 WHERE id 1; -- 当前读 COMMIT;问题来了事务A读到余额100然后事务B也读到余额100在A没提交前B也是快照读两边同时做扣款最后余额可能变成0但实际理论上应该变成-50的。这个错误在于我用了快照读去“检查”却用当前读去“修改”。快照读看到的状态和当前读实际拿到的状态在并发下可能不一致。正确的做法是要么一开始就用SELECT ... FOR UPDATE做当前读把这一行锁住再基于它做业务判断和修改要么就在UPDATE语句里直接带上余额条件UPDATE account SET balance balance - 50 WHERE id 1 AND balance 50;这样就把检查放到了原子操作里不需要先读再改从根上避免了并发下的判断失效。这条经验非常实用建议所有做金融、库存类业务的朋友都记下来。5.3 从实战角度理解MVCC的意义说到底MVCC这套机制设计的初衷就是让“读”和“写”尽量不互相阻塞从而支撑起高并发的读写负载。在理解它之前你可能遇到查询慢、死锁、数据不一致时只会一根筋地加索引或者粗暴地升级隔离级别理解它之后你会习惯性地去思考这个事务是多长它锁了哪些行它的ReadView是什么时候生成的它能读到什么版本这种思维方式的转变才是读这篇文章最有价值的地方。不夸张地说看懂MVCC之后你对数据库的理解会明显上一个台阶——从“会用”到“知道它在干什么”这个门槛跨过去之后你的调优能力、排查问题能力都会有本质提升。这东西就跟游泳一样看着别人在水里扑腾很简单但真换成你自己下水只有搞清楚原理、规范动作才能少呛几口水。