数据库并发控制与锁机制：从两段锁到隔离级别实战解析

最近在重读陈红、卢卫老师的《数据库系统概论》并发控制部分，起因是团队里有几个开发同学写接口时把事务开得特别大，结果生产库的锁等待直接飙红，一条简单查询硬生生等到超时。我借着这个机会，把教材第12章“并发控制”和平时踩过的坑放在一起完整过了一遍，越看越觉得这一章不是理论摆设，它就是数据库隔离性落到实处的底层逻辑。这篇笔记适合正在啃数据库课程的学生、准备软考或考研复试的朋友，以及那些每天写SQL但对锁的机制模棱两可的开发。

并发控制的核心问题，一句话就能说清：多个事务同时访问同一批数据，既要跑得快，又不能把数据弄错。教材一上来就用并发操作带来的三类异常做铺垫，丢失修改、不可重复读、读脏数据，后面再引出锁、封锁协议、两段锁、死锁处理，层层递进。这一篇我们完整拆掉“冲突可串行化”这条判断主线，再把锁机制和死锁讲透，最后接到真实数据库的隔离级别上，让课本知识和你的日常工作对上号。

1. 并发控制到底在防什么：三个经典事故现场

1.1 事务的ACID与并发执行之间的天然矛盾

数据库里的事务，最核心的四个性质不用多背：原子性、一致性、隔离性、持久性。其中隔离性说的是，多个事务并发执行的效果，应该和它们串行执行的效果一致。如果数据库傻乎乎地只允许一个事务完整跑完再跑下一个，隔离性天然成立，原子性也容易保证，但系统的吞吐量会低到没人敢用。现代数据库面对的往往是成千上万个并发请求，读写必须交错执行才能把CPU、磁盘、网络都利用起来。

这个矛盾就是并发控制要解决的起点。并发执行能提高资源利用率，但也会让事务之间互相干扰，破坏隔离性。你可以在脑海里打个比方：多个厨子共用一间厨房，如果每个人做完一道菜才能让下一个人进场，效率太低；如果所有厨子同时开火，就可能出现一个人拿走了另一个人刚调好的酱汁、炒到一半锅被换走的情况。数据库并发控制就像厨房管理制度，既要让多个厨师同时干活，又要保证每道菜最终的出品是对的。

1.2 丢失修改：两个事务互相覆盖造成的“账目对不上”

先看一个最经典的问题。假设库存表里某个商品的库存量是100，事务T1要卖出一个，事务T2也要卖出一个。正常的业务逻辑是，每完成一单，库存减1，最终应该是98。

但并发执行时可能会发生这样的时间线：T1先读取库存，得到100；T2也在这个时刻读取库存，同样得到100；T1计算100减1等于99，把99写回数据库；T2也按自己手里的100计算，得到99并写回数据库。最终库存停在99，T1的修改被T2的写操作覆盖了，两笔卖出只扣了一个库存，这就是丢失修改。

教材里为什么强调要先用X锁才能解决这个问题？因为丢失修改的本质是两个事务对同一份数据同时“读旧值、算新值、写回去”，中间没有互斥。只要保证“写之前必须先拿到排他锁，而且这个锁要一直持有到事务结束”，另一个事务就只能在旁边等，等你提交或回滚之后才能读到这个已经被扣减过的库存值。数据库专业课里把这个叫做一级封锁协议，看起来很简单，实则是很多企业生产事故的原始根源。

1.3 读脏数据与不可重复读：读的一方也可能被“坑”

写写冲突会丢修改，读写冲突则会产生另外两类问题。读脏数据发生在“一个事务读到了另一个事务还没提交的修改”。比如账户余额初始是50，T1想把余额改成20，它在内存里改了但还没提交；这时T2跑过来读余额，读到的是20，然后基于20继续做了后续计算。紧接着T1发现业务异常，执行回滚，余额又恢复成50。T2刚才等于拿了一个从来没有真正存在过的数据当依据，这就是脏读。

不可重复读则是同一个事务内，同一条查询语句在不同时间读到不同的值。典型场景是T1先读账户A的余额，得到100；这时候T2对A扣了50并提交，A余额变成50；T1再次读A，读到的就是50。在串行执行的情况下，无论T2在T1之前还是之后跑，T1两次读A都应该是一致的，不会读到“一半是T2之前的状态、一半是T2之后的状态”。

教材上还把幻读归为不可重复读的一种特殊情况：T1按某个条件查询出一批记录，T2在这期间插入了一条满足条件的新记录并提交，T1再查一次，结果集多出一行“幽灵记录”。幻读和普通不可重复读的区别在于，普通不可重复读针对的是某一条已有数据被修改，幻读针对的是整个结果集的记录数发生变化。要防住幻读，只锁某一条数据是不够的，必须锁住一个范围，这也是后来要多粒度封锁、间隙锁这些东西的原因。

2. 判断并发调度正确性的标尺：可串行化与冲突可串行化

2.1 可串行化：一个直观但不好直接验证的“黄金标准”

在讨论锁怎么做之前，得先回答一个更基本的问题：并发执行到底做到什么程度算“正确”？教材给的标准答案叫可串行化。把多个事务交错执行的操作顺序称为一个调度，如果某个并发调度的执行结果，和这些事务按某种串行顺序逐个执行的结果一样，那这个调度就是可串行化的。

这个定义很优雅，因为每个事务单独执行时，只要业务逻辑正确，数据库状态最终就是正确的。既然如此，并发调度只要能和某个串行顺序的结果“打平”，就算没有破坏一致性。但问题也很明显：怎么判断结果是否等价？总不能每次执行完把数据库终态拿来比一比，先不说状态空间有多大，很多场景下不同串行顺序的结果本身可能不同，终态相同也不能说明过程没有隐藏的时序风险。

所以教材引出一个在实际判定中更常用的工具：冲突可串行化。注意，冲突可串行化是可串行化的充分条件，不是必要条件。也就是说，一个调度只要冲突可串行化，就一定能推出它是可串行化的；但反过来，一个可串行化的调度不一定必须满足冲突可串行化。数据库的锁机制在绝大多数情况下追求的目标，就是让生成的调度满足冲突可串行化。

2.2 冲突操作的含义：为什么读读不冲突而读写必须严格排序

两个操作之间会不会“打架”，取决于两个条件：它们来自不同事务，它们操作的是同一个数据项，并且至少其中一个是写操作。读读组合只有读，谁都改不了数据，谁先谁后都不影响最终结果，所以不冲突。读写组合和写写组合就不一样了，先读后写还是先写后读，会直接影响事务看到的值以及数据库的最终状态，因此必须判定为一个冲突对。

把事务想象成在同一个白板上写字和看字的人。两个人同时看白板上的同一行字，没有任何问题；一个人看、一个人改，先看后改和先改后看得到的内容完全不同；两个人同时改，更是只能有一个人赢。数据库里的冲突判定，就是把白板上的问题用规范化语言表达出来。

为什么可串行化判定不直接比较结果，而要绕着冲突走？因为数据库很难预先枚举所有可能的串行顺序，而冲突关系是局部的、可以静态分析的。它把问题转化为“调度中不同事务的相对顺序是否一致”：如果事务T1的某个操作与T2的某个操作冲突，并且T1的操作在时间上先发生，那么在任意等价的串行顺序里，T1都必须排在T2前面。如果这种先后关系形成矛盾，那这个调度就无法映射到任何合法的串行执行。

2.3 用前驱图判定一个调度是否冲突可串行化

教材里给出的判定工具叫前驱图，也叫优先图。做法分三步。第一步，把每个事务画成一个节点。第二步，逐对检查所有冲突操作：如果T1的某操作与T2的某操作冲突，并且T1的操作在调度中先执行，那么从T1画一条有向边到T2。第三步，看这个有向图里有没有环，无环则调度冲突可串行化，有环则不行。

举个例子。两个事务都做同一件事：先读数据A，再写数据A。现在有一种交错调度：T1读A，T2读A，T1写A，T2写A。画前驱图时，先看T2的读和T1的写，T2读A发生在T1写A之前，所以有一条边从T2指向T1；再看T1的读和T2的写，T1读A发生在T2写A之前，于是又有一条边从T1指向T2。两条边构成了一个环，这个调度就不是冲突可串行化的。实际上这个调度正是前面丢修改的一种典型过程，最终的写覆盖让T1的修改丢失了。

反过来，如果一个调度里，T1先完成A上的读和写，T2再完成A上的读和写，边只从T1指向T2，没有环，那它显然可以等价为T1串行再T2的执行。注意，判断过程本身不需要看具体业务数据是什么，只需要操作序列和冲突规则，这也正是数据库系统能够在运行时快速决策的基础。

3. 锁机制：从锁类型到封锁协议，再到两段锁

3.1 两种基本锁：共享锁与排他锁的兼容矩阵

说到锁，先从最基础的两种类型开始。排他锁也叫X锁，事务对数据项加上X锁之后，其他事务对这个数据项的任何加锁请求都会被拒绝，直到X锁释放。共享锁也叫S锁，加S锁之后，其他事务还可以继续加S锁进行读操作，但不能再加X锁进行写操作。两种锁的兼容规则可以整理成一张矩阵：S锁和S锁兼容，S锁和X锁互斥，X锁和任何锁都互斥。

为什么不干脆只设计一种排他锁？如果读操作也要拿排他锁，那所有读同一份数据的事务之间就无法并行，系统的读并发能力会断崖式下降。绝大多数业务场景是读多写少，让读读共享、把读写和写写互斥开，是性能和正确性之间一个很务实的折中。

这一节需要特别说清楚的一点：锁本身只定义了加锁之后的访问权限，它没有规定“什么时候加锁、什么时候释放锁”。两个事务都可以在合适时机申请X锁，但如何设计申请和释放的时机，才能避免丢失修改、脏读、不可重复读，甚至保证可串行化，这是封锁协议要回答的问题。

3.2 三级封锁协议：每一级能解决什么，不能解决什么

一级封锁协议解决的是丢失修改，但用的是最粗暴的方式：事务在修改数据之前必须加X锁，而且这个X锁要一直持有到事务结束。注意这里有个容易被忽略的细节，一级协议只约束写操作，没有约束读操作。因此它挡不住读脏数据，也挡不住不可重复读。

二级封锁协议在一级的基础上增加了读操作的要求：读数据之前必须加S锁，读完后可以立即释放。加S锁意味着什么？意味着另一个持有X锁、正准备修改这份数据的事务会被挡在外面，事务在读数据的过程中，别人改不了这份数据，脏读就被防住了。但S锁读完就释放，T1第一次读完A之后，T2就能修改A并提交，等T1第二次再读A时，数据已经变了，所以二级协议仍然防不住不可重复读。

三级封锁协议把读锁的释放时机推到事务结束：读数据前加S锁，S锁和X锁一样，都要到事务结束才释放。这样一来，事务执行期间，它读过的数据不会再被其他事务修改，不可重复读被防住了，幻读在单条数据层面也被一起防住了。把三级协议放在一起看，就是从只锁写、到写读都锁、再到所有锁都维持到事务结束，一个逐步收紧的过程。

3.3 两段锁协议：为什么它能保证冲突可串行化

三级封锁协议在解决三类现象上表现不错，但还不够。一个隐含的问题是，即使每个事务内部都遵守三级协议，由这些事务组成的整体调度仍然可能不是可串行化的。原因在于，三级协议没有约束事务之间的加锁顺序，而可串行化要求所有事务在冲突数据项上的操作顺序全局一致。

两段锁协议就是给所有事务加了一条更严格的纪律：事务中的加锁操作分成两个阶段，在增长阶段只能加锁不能释放锁，一旦进入收缩阶段，只能释放锁不能再加新锁。一个事务把所有需要的锁都拿到手再开始释放，称为满足两段锁协议。

为什么满足两段锁协议的调度一定是冲突可串行化的？可以这样理解：一个事务在进入收缩阶段之前，它拥有所有它需要的数据项的锁；另一个事务如果和它有任何冲突操作，必须先等它释放才能继续。所有冲突的边方向都指向那个先进入收缩阶段、也就是先释放锁的事务，这样一来，有向图里不可能出现那种“T1等T2、T2又等T1”的环路。教材直接给出了结论：若所有事务均遵守两段锁协议，则这些事务的任何并发调度都是可串行化的；反过来，一个可串行化调度中的所有事务并不一定都满足两段锁协议，它只是一个充分条件。

这地方初学者特别容易混淆，我拿自己的经历说一句：当年我把“两段锁”和“三级封锁协议”看成并列的技术方案，后来才发现它们是不同层面的东西。三级封锁协议解决的是“具体数据异常”，两段锁协议解决的是“全局调度正确性”。实际数据库把两者结合起来使用：用锁类型控制访问权限，用锁的持有时间控制异常现象，用两段锁的纪律保证最终调度的可串行化。

4. 锁带来的新麻烦：活锁、死锁的预防与处理

4.1 活锁与死锁：封锁系统的两个常见副作用

加锁在防数据异常的同时，也把并发系统推入了另一个风险区：事务可能因为等锁而永远得不到执行机会，或者互相等锁直到系统僵住。

活锁在教材里讲得不多，但实际很容易理解。一个事务T1想对数据项R加锁，结果系统总把加锁机会优先给后到达的其他事务，T1就一直排队等着，好像被“饿”住了。数据库里解决活锁的常见策略是先来先服务，也就是按照请求加锁的先后顺序排队等待，不让后来者插队，保证每个事务最终都能拿到锁。

死锁比活锁严重得多。两个事务T1和T2，T1锁住了数据A并想申请数据B的锁，T2锁住了数据B并想申请数据A的锁，谁都不愿意先释放自己手里的锁，系统就卡死了。死锁的产生和操作系统教材里讲的条件同源：互斥、占有并等待、不可剥夺、循环等待。在数据库场景下，数据项上的S锁和X锁天然互斥；事务在持有部分锁的同时还会申请新的锁；已经获得的锁不能被系统强行抢走；多个事务在等待关系上形成闭环。

4.2 死锁预防：一次封锁法与顺序封锁法的取舍

预防的思路是打破死锁产生的必要条件，主要做法有两条路线。一条叫一次封锁法，它要求每个事务在开始执行时，一次性把所需的所有数据项都加锁。听起来很彻底，但问题在于事务在执行之前很难预知自己到底会用到哪些数据，尤其是有条件分支和动态SQL的场景；即使能预知，把所有数据都锁在手里会严重降低并发度，因为可能在很长时间里用不到其中一部分锁。性能代价太大。

另一条叫顺序封锁法，要求所有事务按照预先约定的顺序对数据项加锁。举个例子，把所有数据项排成固定序号，事务只能从小到大申请锁，不允许回头申请序号更小的锁。这样两个事务即使都想互相等待，也只会朝同一个方向等，形不成环路。这个方法的隐患也很明显：数据项非常多，维护一个全局统一的访问顺序本身就是额外成本，业务数据之间的访问关系还经常是复杂的网状结构，硬要排序并不现实。

所以大部分商用数据库不会痴迷于死锁预防，而是把功夫花在死锁检测和恢复上。

4.3 死锁检测与恢复：等待图、超时与牺牲者的选择

检测死锁有两种常见手段。超时法最简单，给锁等待设置一个时间上限，超过就认为可能发生了死锁，让事务回滚重试。优点是开销小，缺点是把一些只是慢的长事务误判为死锁，阈值设置要仔细权衡。等待图法更准确，数据库系统持续维护一张以事务为节点、以等待关系为边的有向图，事务Ti等待Tj持有的锁，就画一条从Ti指向Tj的边。系统周期性地检测这张图，一旦发现回路，就判定发生了死锁。

死锁一旦被检测到，恢复过程就要做“牺牲者选择”：从等待环中挑出一个事务回滚，释放它持有的锁，让其他事务继续跑。回滚谁，是个策略问题。最朴素的选择是回滚代价最小的事务，比如事务当前执行了多少操作、已经持有了多少锁、还差多少能完成，这些都影响代价。另一个必须考虑的问题是防止某个事务总被选为牺牲者而被无限回滚，也就是活锁里的“饿死”问题，教材里的思路是结合事务的执行次数和代价做一个综合权衡，尽量做到公平。

需要强调，死锁恢复里的“回滚”不一定总是把整个事务全部撤销。如果数据库支持保存点，可以把事务回滚到某个保存点，只撤销后面一部分操作，然后尝试重新执行，这样可以减少回滚代价。真实数据库里，这条思路和事务日志、保存点机制是紧密关联的，以后做数据库故障恢复时还会再碰到。

5. 把教材知识接到真实数据库：隔离级别与工程实践

5.1 隔离级别：SQL标准对封锁协议的一次“产品化封装”

教材讨论的锁与封锁协议，到了工程层面被封装成了一个更容易理解的概念：事务隔离级别。SQL标准定义了四档隔离级别，从宽松到严格依次是读未提交、读已提交、可重复读、可串行化。它们和前面讲的三级封锁协议有清晰的对应关系。

读未提交约等于“基本不设防”，事务能读到其他事务未提交的数据，脏读、不可重复读都可能发生。读已提交在每次读之前会拿到S锁但读后就释放，脏读被防住，接近二级封锁协议的效果。可重复读在事务整个期间保持S锁和X锁，不可重复读被防住，接近三级封锁协议的效果。可串行化是最高档，会通过更强的锁机制或串行化执行保证所有可能的并发问题都被防住。

对开发人员来说，隔离级别是把复杂的加锁协议抽象成一行配置，但抽象的好处也带来了坏处：很多人只知道“我把隔离级别调高一点就行”，却不清楚调高背后是更多的锁占用和更低的并发度。生产环境最常见的问题是，系统把隔离级别设得太高，又开着长事务，完全没意识到数据库在背后给你挡了多少并发请求。

5.2 长事务与大事务：并发控制实践中最大的敌人

我在实际工作中反复印证过一件事：锁机制本身不是故障源，长事务才是。有些事务里塞了几十次查询、一次外部API调用、甚至一个报表导出逻辑，事务迟迟不提交，持有的锁就迟迟不释放，后面所有访问同一批数据的事务只能排队。

有一次线上排查，某张业务表在高峰期出现了大量锁等待超时，追了半天发现是一个凌晨跑的批处理任务占用了一批行锁，和白天正常交易事务发生冲突。批处理本身逻辑没错，错在把几万行数据的更新放在一个事务里执行，导致事务运行时间非常长。解决思路很简单：把大批量更新拆成小批次，每个批次单独提交，缩短每条UPDATE语句持有锁的时间，冲突概率立刻降下来了。

另外一个常见的坑是事务里混入外部服务调用。你持有着数据库锁去调第三方接口，没人知道第三方会响应多久，锁被无限期地握在手里。实践原则是：开事务前准备好所有需要的外部数据，事务内只做数据库操作，快速提交。

5.3 学完这节之后，我建议你能做一次真实系统的“锁观察”

这一章的理论含量不小，但如果不落到实操上，很容易学过就忘。我建议有条件的话，在你常用的数据库上做一个实验：开两个客户端连接，手动开启事务，先在一个连接里更新一行数据但不提交，再到另一个连接里去读或者更新同一行，观察它的阻塞情况；再查一下数据库提供的锁等待视图，比如MySQL里可以通过information_schema.innodb_trx、performance_schema等表看到当前事务的等待状态。把教材里的时间线画在纸上，再亲眼看到数据库行为，很多抽象的概念一下就通了。

我自己一路啃下来的感受是，并发控制最考验人的地方不是背概念，而是要把“一个事务的内部顺序”和“多个事务之间的交错顺序”在脑子里同时画出来。你如果能随手写出一个调度、标出哪些操作冲突、画出前驱图、判断有没有环，再解释清楚一级、二级、三级封锁协议各自堵住了哪个漏洞，这一章的上半部分就真的学扎实了。