数据库并发控制是数据库原理课程中承上启下的部分也是实际开发中出现线上故障的高频来源。很多学生在准备数据库考试时能背出 ACID 的定义却很难解释“为什么 REPEATABLE READ 下还可能出现幻读”“死锁日志应该怎么读”“两段锁协议和加锁顺序有什么关系”。这篇内容围绕数据库并发控制展开把事务并发异常、锁机制、时间戳、MVCC、隔离级别和死锁排查串成一条完整链路同时给出常见的简答题答题模板。它适合备考数据库课程与考研复试的读者也适合工作中排查事务超时、死锁和隔离级别选型问题的开发人员。在继续之前先说明一个原则并发控制不是数据库自己默默完成的魔法。它是一套由锁、版本链、日志和调度规则组成的可解释机制。只要把“为什么会有并发问题”和“数据库用什么手段去抑制这些问题”理清楚考试和排错就都不难。1. 并发控制要解决的是什么问题理解并发控制之前必须先理解“没有它会发生什么”。数据库支持多个事务同时执行是为了提高资源利用率和系统吞吐量但并发执行如果完全不加限制会破坏事务原本应该保持的正确性。这种正确性的评判基准是事务串行执行时的结果。1.1 一个并发事故丢失修改是怎么发生的假设有一张账户表A 账户余额为 100 元。事务 T1 要做 A A 50事务 T2 要做 A A - 30两个事务几乎同时发起并且都先读取到了 A 100时间顺序事务 T1事务 T2A 的实际值1读取 A得到 1001002读取 A得到 1001003把本地值 100 50写回 A 1501504把本地值 100 - 30写回 A 7070最终 A 等于 70。但如果按 T1、T2 串行执行正确结果应该是 T1 先加 50 得到 150T2 再减 30 得到 120。这个例子就是最典型的“丢失修改”两次写操作基于同一个旧值计算后写覆盖先写其中一次修改丢失了。丢失修改之所以发生是因为两个事务对同一数据对象的“读-算-写”过程交叉执行却没有相互隔离。数据库并发控制的首要目标就是避免这种交叉导致的结果错误。1.2 从 ACID 到隔离性事务有四个基本特性原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability。其中隔离性说的是多个事务并发执行时一个事务内部的操作对其他事务不可见一个事务执行过程中使用的数据不应该被其他未完成事务随意改变。用户要求的“并发控制”在数据库课程中通常被放在“事务隔离性”之后讲原因就是并发控制是隔离性的实现手段。没有并发控制隔离性就是一句空话没有隔离性事务的一致性也无法保证。这里要区分两个概念并发执行多个事务在时间上重叠执行提高效率。并发控制通过调度机制让这些重叠执行在结果上等价于某个串行结果。如果一个并发调度的执行结果与这些事务按某种串行顺序执行的结果相同就称该调度是可串行化的调度。可串行化是并发调度的正确性标准。1.3 为什么不能简单地禁止并发最简单的方法是把所有事务排成队列一次只让一个事务执行。这种方法在正确性上没有问题但吞吐量会低到难以接受。在银行、电商、订单系统里同一时刻可能有成千上万个事务排队如果数据库只能串行执行系统基本无法提供服务。并发控制的本质是在“正确性”和“并发度”之间做权衡。选择不同的控制机制就会得到不同的隔离程度隔离程度越高正确性越好并发度越低。理解这一点后面再看隔离级别和 MVCC 就会轻松很多。2. 基于锁的并发控制从两段锁协议到意向锁最经典的并发控制方法是加锁。锁的思想很直接事务在访问数据之前先申请锁申请成功后持有锁访问结束后释放锁。其他事务在锁被释放前不允许进行冲突操作。2.1 共享锁、排他锁与锁兼容矩阵数据库中的基本锁有两种共享锁S 锁Shared Lock允许持有锁的事务读数据不允许写数据。多个事务可以同时持有同一数据对象上的共享锁。排他锁X 锁Exclusive Lock允许持有锁的事务读和写数据同一时刻只允许一个事务持有排他锁。两个事务在同一数据对象上的锁兼容性由下面的矩阵决定当前事务已持有新事务申请 S 锁新事务申请 X 锁无锁兼容兼容S 锁兼容不兼容X 锁不兼容不兼容S 锁和 S 锁可以同时存在因为它们都只读S 锁和 X 锁不能同时存在因为持有 S 锁的事务在读持有 X 锁的事务在写写会破坏读的一致性X 锁和 X 锁更不能同时存在。在 MySQL InnoDB 中普通 SELECT 使用的是一致性读不加共享锁只有手动SELECT ... FOR SHARE才会加 S 锁SELECT ... FOR UPDATE才会加 X 锁。这个细节后面结合 MVCC 再展开。2.2 两段锁协议为什么能保证可串行化仅仅在每个数据操作前加锁还不够。如果事务在操作过程中随意释放锁依然可能出现不可串行化的结果。数据库课程里对此的解决方案是两段锁协议Two-Phase Locking2PL。两段锁协议把每个事务分成两个阶段扩张阶段事务可以申请新锁但不能释放任何锁。收缩阶段事务可以释放锁但不能申请新锁。也就是说一旦事务开始释放锁就不能再加锁。2PL 协议保证任何满足该协议的事务调度都是冲突可串行化的。原因是它能防止一个事务在释放锁之后又申请新的锁从而避免调度过程中出现冲突边形成的环。这里需要说明一个容易混淆的点常用数据库默认的锁粒度不是简单的“读加 S、写加 X”而是在 SQL 执行级别按照语句需要分配锁。2PL 是数据库课程的理论基础在实际 InnoDB 中行锁通常也是直到事务提交或回滚才释放这和严格两段锁协议中的“严格”一致。两段锁协议并不是没有代价。一个事务持有的锁越多、时间越长其他事务被阻塞的概率越大死锁的风险也随之增大。第二个常见坑是锁的释放时机不能只盯着语句结束而要盯着事务边界。2.3 锁粒度与意向锁锁可以加在不同粒度上行、页、表、库。加锁粒度越小并发度越高但锁的管理开销越大粒度越大开销越小但并发度越低。为了同时支持表级锁和行级锁InnoDB 还引入了意向锁。意向锁是一种表级锁它表示“某个事务准备在表里的行上加锁”的意图意向锁类型含义意向共享锁IS事务准备在表中某些行上加 S 锁意向排他锁IX事务准备在表中某些行上加 X 锁意向锁的意义在于快速判断表上是否存在不兼容的锁。如果事务要对整张表加 X 锁它需要先确认表中没有任何行被其他事务锁住。如果没有意向锁数据库需要扫描所有行才能确认有了意向锁只需检查表级是否有 IX 或 X 意向锁即可快速得多。实际排查锁竞争时如果看到TABLE LOCK ... IX不要急着认为“表被锁死了”。IX 锁只是意向真正阻塞的是行级 X 锁或间隙锁。3. 基于时间戳的并发控制另一种正确性保障思路锁机制是“操作之前先申请冲突就等待”。时间戳机制换了一个思路每个事务进入系统时获得一个唯一的、单调递增的时间戳系统根据时间戳决定事务操作的顺序。时间戳小的先执行时间戳大的后执行。3.1 时间戳排序算法是如何判断的时间戳排序算法为每个数据对象维护两个标记R-Timestamp已经成功读取该数据对象的事务中最大的时间戳。W-Timestamp已经成功写入该数据对象的事务中最大的时间戳。当一个事务 T 要执行读操作 R(x) 时规则如下如果 TS(T) W-Timestamp(x)说明已经有更晚的事务写入了 xT 读到的是旧值违反时间戳顺序因此拒绝该操作回滚事务 T。否则允许读并把 R-Timestamp(x) 更新为 max(R-Timestamp(x), TS(T))。当一个事务 T 要执行写操作 W(x) 时规则如下如果 TS(T) R-Timestamp(x)说明已经有更晚的事务读过了 x再写会破坏它的读取结果拒绝并回滚 T。如果 TS(T) W-Timestamp(x)说明已经有更晚的事务写过了 x这时可以忽略这次写不用回滚。否则允许写并把 W-Timestamp(x) 更新为 TS(T)。下面是一个非常精简的伪代码示例用于说明“判断-允许-拒绝”的过程function read(x, T): if TS(T) W_TS[x]: rollback(T) else: allow_read(x, T) R_TS[x] max(R_TS[x], TS(T)) function write(x, T): if TS(T) R_TS[x]: rollback(T) else if TS(T) W_TS[x]: ignore_write(x, T) else: allow_write(x, T) W_TS[x] TS(T)实际数据库很少直接纯用这种时间戳调度但理解它仍然有价值它避免了锁等待却需要用频繁回滚来保证正确性。当一个事务操作顺序过于“落后”时它会被强制回滚这在高峰期会放大系统负载。3.2 时间戳机制与锁机制的对比对比维度基于锁的 2PL基于时间戳的调度冲突处理方式冲突时等待冲突时回滚事务是否需要排队需要等待锁释放基本不等待回滚频率死锁时才回滚一个事务时间戳落后就可能回滚实现复杂度需要锁表、死锁检测需要维护时间戳和标记强调顺序通过锁获得串行化效果通过预先分配的顺序约束实际生产环境通常不会只使用一种机制。InnoDB 以行锁为主同时用 MVCC 处理读请求某些分布式数据库则用时间戳和全局时钟来编排事务顺序。考试中如果问“时间戳协议的优点”重点答“避免死锁和锁等待”如果问缺点重点答“回滚开销大、可能产生级联回滚”。4. MVCC多版本并发控制是如何减少锁冲突的MVCC 是当前主流数据库引擎处理读写并发时最核心的机制。它最大的特点是读操作不阻塞写操作写操作也不阻塞读操作。早先的加锁方案中一个事务读数据时如果另一个事务正在写读事务必须等待MVCC 则通过保存多个版本的数据快照让读事务读取某个合适的旧版本从而避开锁冲突。4.1 MVCC 的核心思想MVCC 的核心是在存储层为每一行数据维护多个历史版本。事务修改某一行时不直接覆盖旧值而是生成一个新版本旧版本仍然保留在 undo log 中。当一个事务需要读某一行时根据自己创建时刻的快照信息从版本链中选择一个可见版本。这样一来写事务只锁住自己修改的那一行不必阻塞其他读事务。读事务不会等待写事务释放锁只需要判断哪些版本对当前事务可见。读和写之间互相解耦系统并发度大幅提升。MVCC 通常和普通行锁搭配使用写操作仍然需要 X 锁读操作在快照读场景下不加锁。4.2 undo log 版本链与 ReadView在 InnoDB 的行结构中有两个隐藏列DB_TRX_ID表示最近修改该行的事务 IDDB_ROLL_PTR指向该行在 undo log 中的上一个版本。多个版本通过回滚指针串成一条版本链。当事务需要判断某个版本是否可见时会生成一个 ReadView。一个 ReadView 主要包含四部分字段含义m_ids生成 ReadView 时当前尚未提交的事务 ID 列表min_trx_idm_ids 中最小的事务 IDmax_trx_id下一个待分配的事务 ID即当前系统中最大事务 ID 1creator_trx_id创建该 ReadView 的事务 ID判断某个版本是否对当前事务可见的简化流程是如果版本的事务 ID 等于 creator_trx_id说明是事务自己修改的可见。如果版本的事务 ID 小于 min_trx_id说明修改该版本的事务在 ReadView 创建前已经提交可见。如果版本的事务 ID 大于等于 max_trx_id说明该版本由未来事务修改不可见。如果版本的事务 ID 在 min_trx_id 和 max_trx_id 之间并且出现在 m_ids 中说明还未提交不可见如果不在 m_ids 中说明已经提交可见。如果当前版本不可见就沿着版本链继续找下一个版本直到找到可见版本。4.3 快照读与当前读MVCC 解决的主要是快照读也就是普通SELECT。这种读不加锁读取的是某个时间点的快照。尤其在 REPEATABLE READ 隔离级别下事务第一次执行快照读时会生成 ReadView之后整个事务都复用这个 ReadView所以反复执行同样的SELECT结果一致。另一类操作是当前读包括SELECT ... FOR UPDATE SELECT ... FOR SHARE UPDATE table SET column value WHERE ... DELETE FROM table WHERE ...当前读读取的是数据的最新已提交版本并且会对命中的记录加锁。更新和删除操作本质上要先找到最新版本然后加 X 锁。也就是说MVCC 只负责“读”的部分真正写的时候还是要回到锁机制上。这也是为什么在高并发更新同一个热点行时MVCC 并不能完全避免等待写和写之间仍然互斥多个事务同时UPDATE同一行时后面的事务依然会等待前面事务提交。5. 事务隔离级别理论一致性在工程中的折衷数据库课程给出的隔离级别标准是 SQL 标准中的四种它们的区别本质上是“允许哪些并发异常发生”。隔离级别越高并发异常越少但并发性能越差。5.1 四种隔离级别与并发异常隔离级别脏读不可重复读幻读实现基础READ UNCOMMITTED可能可能可能基本不加读锁READ COMMITTED禁止可能可能每句读生成新快照REPEATABLE READ禁止禁止可能需结合实现首次读生成快照后续复用SERIALIZABLE禁止禁止禁止读也加锁或使用严格串行化这里要特别区分三个异常脏读读到了另一个事务尚未提交的数据。如果那个事务回滚读到的信息就是错误的。不可重复读同一个事务内两次读取同一条记录结果不同。原因是被其他事务修改并提交。幻读同一个事务内两次执行同一范围查询第二次出现了第一次没有的行或者少了一部分行。原因是其他事务插入了新行或删除了旧行。在大多数教材中不可重复读强调“记录内容被改”幻读强调“记录集合发生变化”。这个判断标准在答题和面试中非常常用。5.2 不同数据库的默认隔离级别为何不同MySQL InnoDB 的默认隔离级别是 REPEATABLE READ。它通过 MVCC 保证普通快照读不出现不可重复读又通过间隙锁和 next-key lock 在一定程度上抑制了幻读。所以 InnoDB 的 REPEATABLE READ 在实际效果上更接近 SQL 标准中的 SERIALIZABLE但成本是更复杂的锁和更高的死锁概率。Oracle 的默认隔离级别是 READ COMMITTED。它采用语句级一致性读取每次语句执行前生成一个最新的快照因此在同一事务内两次查询可能看到不同结果。这种取舍换来了更少的锁冲突。PostgreSQL 也使用 MVCC默认隔离级别同样是 READ COMMITTED但它的 REPEATABLE READ 会完整抑制幻读。学习环境里可以这样实验-- 会话 A 和会话 B 先开启事务 START TRANSACTION; SELECT * FROM account WHERE id 1; -- 会话 B 修改并提交后回到会话 A 再次查询如果发现两次查询结果一致说明当前隔离级别下的快照读拒绝了不可重复读如果想观察不可重复读可以显式把隔离级别改成 READ COMMITTED。5.3 生产环境选型建议不要为了省事把所有事务都改成 SERIALIZABLE。序列化隔离级别虽然最安全但读操作也会被写阻塞系统吞吐量会明显下降。选型时可以按业务优先级判断场景推荐隔离级别说明金融转账、余额强一致SERIALIZABLE 或应用层锁正确性优先接受性能下降电商订单、库存系统READ COMMITTED 或 REPEATABLE READ注意热点行更新和死锁报表、分析型大量读READ COMMITTED减少锁竞争业务可接受轻微不一致主从复制架构与 MySQL 官方建议保持一致避免 binlog 模式下日志与数据不一致在生产环境调整隔离级别之前必须先确认框架和中间件连接池的事务配置以及 binlog 格式。否则即使改了transaction_isolation部分长事务仍然可能因为历史 SQL 和使用习惯产生意料之外的锁范围。6. 死锁现象、日志与排查链路死锁是并发控制中常见且最让开发头疼的问题。两个或多个事务各自持有一部分资源又都在等待对方释放资源导致环形等待事务永远无法推进。数据库检测到死锁后会选择一个代价较小的事务回滚释放它持有的锁让另一个事务继续执行。6.1 死锁的四个必要条件判断一个场景是否可能发生死锁可以从四个必要条件逐一核查条件含义互斥资源同一时刻只能被一个事务独占使用持有并等待一个事务持有一个资源同时等待另一个资源不可剥夺资源不能被系统强行从持有者手里抢走只能由持有者主动释放循环等待多个事务之间形成等待环一个最常见的 MySQL 死锁场景-- 事务 T1 UPDATE t_order SET status 1 WHERE order_no A001; UPDATE t_order SET status 1 WHERE order_no A002; -- 事务 T2 UPDATE t_order SET status 1 WHERE order_no A002; UPDATE t_order SET status 1 WHERE order_no A001;如果 T1 先锁住了 A001T2 先锁住了 A002然后 T1 再去请求 A002 时发现被 T2 持有T2 再去请求 A001 时发现被 T1 持有两个事务就形成循环等待。解决方式是让所有事务按相同顺序访问相同数据例如都先更新小订单号再更新大订单号。6.2 如何查看死锁日志在 MySQL 中出现死锁时客户端通常收到类似下面的错误ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction要查看详细死锁信息可以在 MySQL 客户端执行SHOW ENGINE INNODB STATUS;输出结果中重点关注LATEST DETECTED DEADLOCK段落。其中会列出产生死锁的两个事务 ID。每个事务最近执行的 SQL。当前持有的锁和正在等待的锁。等待的锁类型是行锁、间隙锁还是插入意向锁。为了更及时拿到死锁日志可以在生产环境开启innodb_print_all_deadlocks ON开启后每次死锁都会写入错误日志便于后续分析。这个参数不是默认开启流量较大的库开启前需评估日志量增长是否可接受。6.3 死锁问题的排查链路遇到“事务执行超时”或“Deadlock found”时建议按下面的顺序排查确认报错类型死锁回滚还是Lock wait timeout exceeded; try restarting transaction等锁超时。前者通常立即报错后者会等待到达innodb_lock_wait_timeout后才报错。打开SHOW ENGINE INNODB STATUS提取两个事务的 SQL 和锁信息。看两条 SQL 是否更新了多张表或多个行是否顺序不一致。看 WHERE 条件是否走了索引。如果没有索引InnoDB 可能需要锁住更多行甚至锁表。看事务时长。事务执行时间越长持有的锁越多死锁概率越高。看应用代码里是否在事务中执行了 RPC 调用、外部 HTTP 请求或长时间等待。修改加锁顺序、缩小事务范围或者对不可避免的冲突重试事务。6.4 避免死锁的工程规范死锁无法完全消灭只能通过设计降低概率并在发生后做重试。落地到代码里可以遵守以下规范多个行更新时先按主键或业务键排序保证所有事务加锁顺序一致。事务内部只做与本次写操作强相关的操作不要把网络请求和文件处理放在事务中。大事务拆成小事务尽量做到“一事务一业务”。更新语句的 WHERE 条件尽量走唯一索引避免间隙锁扩大范围。对高并发热点账户不要反复UPDATE同一个行可以先在内存或 Redis 中累计再批量写库。应用层实现对死锁错误码的捕获和重试重试次数通常为 2 到 3 次。7. 考点拆解与答题模板从理论到考卷这部分是备考复习的重点。数据库并发控制常见题型集中在三类判断并发异常、判断冲突可串行化、解释两段锁协议和死锁。掌握答题模板可以在有限时间内稳定得分。7.1 判断并发异常题题目通常会给出两个事务的操作序列例如T1: R(A), R(B), W(A) T2: R(A), W(A), W(B)答题步骤先列出每个事务的完整操作并标注涉及的数据对象。再按给定调度顺序判断是否存在两个事务读取同一对象但至少一个是写操作的情况。如果存在未提交就读判断为脏读如果提交后被修改导致同一事务前后两次读结果不同判断为不可重复读。如果范围查询的集合发生变化判断为幻读。一段可以直接使用的答题模板“该调度中事务 T1 读取数据 A 后事务 T2 在提交前修改了 A而 T1 在后续步骤继续使用该读值因此发生了脏读。若隔离级别设置为 READ COMMITTED则 T1 在该时刻读取的是 T2 提交后的新值脏读被禁止但可能出现不可重复读。”7.2 冲突可串行化判断题冲突可串行化是考试高频题。先判断哪些操作是冲突操作不同事务、操作同一数据对象、至少一个是写操作。以两个事务为例T1: R(A), W(A), R(B) T2: W(A), R(B)构建优先图如果 T1 的某个操作在 T2 的同对象冲突操作之前则从 T1 画一条边指向 T2反之从 T2 指向 T1。最终如果优先图中有环则调度不是冲突可串行化的无环则存在一个拓扑序对应一个等价的串行调度。答题模板可以写成“冲突操作包括 T1.W(A) 与 T2.W(A)、T1.R(A) 与 T2.W(A)。根据调度顺序T1 中与 A 相关操作先于 T2 中与 A 相关操作因此优先图中存在边 T1 - T2。优先图无环所以该调度是冲突可串行化的等价于串行调度 T1 先执行、T2 后执行。”7.3 两段锁协议与死锁简答题如果题目问“为什么两段锁协议能保证可串行化”从冲突可串行化和锁释放时机两个角度答“两段锁协议要求事务在释放任一锁之后不能再获得新锁因此两个事务对同一数据对象的冲突操作不会出现交叉释放并再次申请的情况。把所有冲突操作按锁申请顺序排布后可以构造出无环的优先图从而保证冲突可串行化。但严格两段锁协议也可能导致死锁因为事务在等待其他事务释放锁时自己持有的锁不会释放。”这类题的得分点在于先定义两段锁再解释它如何消除冲突交叉最后说明它不解决死锁甚至可能增加死锁风险。7.4 综合题给出一段序列判断隔离级别综合题通常给出一段事务操作序列要求选择能达到某种效果的隔离级别。答题时可以按“隔离级别越高并发异常越少但并发度越低”这个主线组织答案同时说明 READ UNCOMMITTED 不能解决任何异常SERIALIZABLE 可以解决所有异常。8. 常见坑与可复用的检查清单最后一个部分汇总实际学习和排错中反复出现的坑。8.1 坑一把脏读和不可重复读混为一谈判断点脏读不可重复读读到的数据来源未提交事务的修改已提交事务的修改发生条件隔离级别低于 READ COMMITTED隔离级别低于 REPEATABLE READ典型表现读到其他事务还没提交的数据可能被回滚同一事务前后两次读同一条记录值不同答题和面试时先说清楚“是否提交”就能很快判断属于哪类问题。8.2 坑二以为 REPEATABLE READ 已经完全消除幻读InnoDB 的 REPEATABLE READ 确实消除了普通快照读的幻读因为整个事务复用同一个 ReadView。但如果使用SELECT ... FOR UPDATE或UPDATE这类当前读仍然可能和插入操作冲突。InnoDB 通过 next-key lock 进一步抑制了部分幻读但也带来区间锁竞争和死锁风险。如果业务对幻读零容忍只改隔离级别还不够还要检查是否存在当前读和范围插入的交叉。8.3 坑三以为事务中行锁在语句结束就释放InnoDB 的行锁通常在事务提交或回滚时才释放而不是 SQL 语句执行完就释放。因此一个事务里如果有多条更新语句后面的语句执行时间越长前面语句持有的锁越久。这在排查锁等待和死锁时非常重要。8.4 可复用检查清单生产环境发布前按下面清单检查一遍[ ] 每个事务是否足够短有没有非数据库操作混入事务。[ ] 多条数据更新是否按固定顺序执行。[ ] UPDATE、DELETE 的 WHERE 条件是否走索引。[ ] 隔离级别是否经过业务评审而不是全库统一改。[ ] 是否开启死锁日志是否有死锁告警。[ ] 热点行更新是否做排队或累加处理。[ ] 数据库连接池和事务边界是否配置正确。复习考试前按“ACID - 并发异常 - 锁与 2PL - 时间戳 - MVCC - 隔离级别 - 死锁 - 可串行化判断”这条顺序过一遍再把每类题目各练两到三题知识点基本就能完整串联起来。数据库并发控制的核心判断始终是正确性与并发度之间的折衷。锁机制保证了安全却引入了等待和死锁MVCC 提升了读并发却在写写冲突时仍然依赖锁更高的隔离级别解决更多异常却降低吞吐量。真正理解这些取舍比背下任何一段结论都更有价值。