《数据库并发控制》课件

ComputerScience·DatabaseSystems数据库并发控制事务管理·锁协议·MVCC机制·死锁处理ConcurrencyControlCourseLectureDB数据库系统原理CONTENTSSYLLABUSOVERVIEW课程目录01事务基础ACID特性、事务状态与生命周期模型02锁协议共享锁/排他锁、两阶段锁与意向锁机制03MVCC多版本并发控制版本链、ReadView与快照隔离实现原理04死锁与高级机制死锁检测、预防策略与间隙锁优化05工程实践生产环境调优、监控指标与故障排查DATABASECONCURRENCYCONTROL02H数据库原理SECTIONCHAPTER01事务与并发基础ACID特性、隔离级别与并发异常DATABASESYSTEMSD数据库原理TRANSACTIONConcept什么是事务：从银行转账说起事务是数据库操作的最小逻辑工作单元，其核心价值在于将多个物理操作封装为一个不可分割的整体，确保业务语义在并发与故障场景下的正确性。完整的业务操作单元事务由一个或多个SQL语句组成，代表一个完整的业务操作单元。例如银行转账包含扣款和入账两条UPDATE语句，必须作为一个整体执行，不允许只完成其中一步。从失败中恢复的能力当事务中部分操作失败时，整个事务可以回滚到初始状态，避免数据停留在不一致的中间状态——这是事务区别于普通SQL批处理的核心价值。并发隔离边界多个客户端同时访问数据库时，事务机制为每个操作提供隔离边界，确保各方操作互不干扰，防止读写冲突导致数据错乱。三个原语：BEGIN·COMMIT·ROLLBACKBEGINTRANSACTION标记事务起点，COMMIT提交使修改永久生效，ROLLBACK撤销所有未提交的修改——这三个原语构成了事务管理的基石。DATABASETRANSACTIONACID四大特性详解ACID是事务处理的四大基石：原子性保证操作不可分割，一致性维护业务规则完整性，隔离性屏蔽并发干扰，持久性确保提交后数据永不丢失。ATOMICITY原子性事务中的所有操作要么全部成功提交，要么全部失败回滚，绝不允许停留在部分完成的中间状态，这是通过UndoLog回滚机制实现的。CONSISTENCY一致性事务执行前后数据库必须满足所有预定义的约束和业务规则，如外键约束、余额非负等，它由应用逻辑与数据库约束共同保障。ISOLATION隔离性并发执行的多个事务之间互不干扰，每个事务都感觉自己在独占数据库资源，这是后续锁协议与MVCC机制要解决的核心问题。DURABILITY持久性事务一旦提交，其修改就永久保存在存储介质中，即使系统随后发生崩溃也不会丢失，这依赖于WAL预写日志与崩溃恢复子系统。ConcurrencyANOMALIES并发带来的三大异常现象脏读、不可重复读和幻读是并发事务中最典型的三类异常，它们的本质区别在于读取到的错误数据来源不同。脏读读到未提交的数据事务A读取了事务B尚未提交的修改数据，若事务B随后回滚，事务A持有的就是从未真正存在过的虚假数据。典型场景：事务B将余额从1000改为700但未提交，事务A读到700并据此判断，随后B回滚余额恢复1000，但A已基于错误的700做出不可逆操作。不可重复读同行数据被修改同一事务内用相同查询多次读取同一行数据结果不一致，原因是其他事务在两次读取之间修改并提交了该行。与脏读的关键区别：不可重复读读到的是已提交的真实数据，但破坏了当前事务内部读取结果的一致性预期。幻读行数发生变化同一事务内用相同条件两次查询返回行数不一致，原因是其他事务在两次查询之间插入或删除了满足条件的新行。本质区别：不可重复读是已有行被修改，幻读是行的数量发生变化。InnoDB在RR级别通过Next-KeyLock专门解决幻读。ISOLATIONLEVELSSQL标准四种隔离级别对照SQL标准定义了从低到高四种隔离级别，每一级解决特定的并发异常，隔离级别的选择本质是一致性与吞吐量的权衡。隔离级别脏读不可重复读幻读并发性能READUNCOMMITTED可能发生可能发生可能发生最高READCOMMITTED已解决可能发生可能发生较高REPEATABLEREAD已解决已解决部分解决中等SERIALIZABLE已解决已解决已解决最低默认策略：InnoDB默认使用REPEATABLEREAD，通过MVCC+Next-KeyLock在中等性能下解决了大部分异常。选型建议：业务对一致性要求高选SERIALIZABLE，高并发场景优先READCOMMITTED以换取吞吐量。CHAPTER02基于锁的并发控制2PL协议族、锁粒度与多粒度封锁DATABASELOCKINGCONCURRENCYCONTROL共享锁与排他锁：基本语义共享锁允许多个事务同时读取同一资源，排他锁确保独占写入权限。S-S兼容、S-X互斥、X-X互斥的兼容性矩阵是所有锁协议的基石。共享锁（S锁）READ用于读操作，多个事务可以同时持有同一资源的S锁而互不阻塞，保证了读操作的高并发性。排他锁（X锁）WRITE用于写操作，任何时刻最多只有一个事务能持有某资源的X锁，且X锁与S锁互斥，确保写入过程中没有其他事务能读或写。锁兼容性矩阵定义了并发行为的基本规则：S-S兼容、S-X互斥、X-X互斥，这张矩阵是所有高级锁协议的基础。锁的申请与释放由数据库引擎自动管理：SELECT通常申请S锁，INSERT/UPDATE/DELETE申请X锁，事务结束时自动释放所有持有的锁。锁兼容性矩阵SXS✓兼容✗互斥X✗互斥✗互斥S+S→兼容多事务并发读取S+X→互斥读写不可共存X+X→互斥写写不可共存CONCURRENCYCONTROLDATABASESYSTEMS两阶段锁协议2PL核心规则两阶段锁协议将事务的锁操作严格划分为增长阶段和收缩阶段，这一约束是保证冲突可串行化的充分条件，但基本形式无法避免级联回滚和死锁。图：2PL增长阶段与收缩阶段示意1增长阶段—事务可以获取新的锁但不能释放任何已持有的锁，锁的数量只能单调递增，从事务开始持续到最后一个锁被获取为止。2收缩阶段—事务可以释放已持有的锁但不能获取任何新锁，锁的数量只能单调递减，从第一个锁被释放持续到事务结束。32PL核心定理—任何遵守两阶段锁协议的调度都是冲突可串行化的，这是保证串行化的充分条件但不是必要条件。4基本2PL的局限—无法防止级联回滚（允许提前释放读锁），无法避免死锁（两个事务互相等待对方释放锁）。ConcurrencyControlPROTOCOLS严格两阶段锁S2PL与强严格SS2PLS2PL要求排他锁在事务结束后释放以消除级联回滚；SS2PL进一步要求所有锁都在事务结束后释放，实现更简单且提供提交顺序保证，是工业界事实标准。严格两阶段锁S2PL锁释放约束：在2PL基础上增加约束——所有排他锁必须在事务提交或回滚之后才能释放，共享锁仍可在收缩阶段正常释放。核心价值：保证严格调度，不会出现脏读和脏写，从而彻底消除级联回滚问题。Strict2PL强严格两阶段锁SS2PL锁释放约束：事务持有的所有锁——无论共享锁还是排他锁——都必须在事务结束后才能释放，实际上取消了收缩阶段的概念。工业标准：相比S2PL实现更简单、提供提交顺序保证，且在分布式环境中能自动解决全局死锁，成为工业界事实标准。StrongStrict2PL·IndustryStandardCONCURRENCYCONTROL保守两阶段锁C2PL：预防死锁C2PL通过在事务开始前一次性获取所需的全部锁来破坏占有并等待条件，从根本上预防死锁，但要求预知全部资源需求，实际应用范围有限。核心规则：事务在开始执行前必须一次性获取整个生命周期中需要的全部锁，如果任何一个锁无法立即获得，事务就不持有任何锁地等待或重试。死锁预防机制：通过破坏死锁四个必要条件中的占有并等待条件来预防死锁——事务要么持有全部所需锁开始执行，要么不持有任何锁等待。主要局限：要求事务在执行前就知道需要访问哪些资源，这在复杂的交互式应用或动态SQL场景中几乎不可能满足。思想传承：尽管C2PL本身应用有限，但其预声明资源需求的思想影响了后来的批量锁获取、锁升级策略以及某些分布式事务协议中的资源预留机制。H数据库系统原理CONCURRENCYLOCKGRANULARITY锁粒度：表锁、页锁与行锁锁粒度决定了并发度与开销之间的权衡：粒度越细并发度越高但锁管理开销越大。现代OLTP数据库普遍采用行级锁作为默认粒度。表级锁：粗粒度低开销基本机制：表锁对整个表加锁，实现最简单、开销最小，但任何写操作都会阻塞所有其他事务对该表的访问，仅适用于DDL操作或小表批量导入场景。退化陷阱：当UPDATE/DELETE语句未命中索引时，InnoDB会退化为表锁，这是开发中常见的性能陷阱，务必确保WHERE条件能有效利用索引。LOWOVERHEAD锁粒度粗·并发度低行级锁：细粒度高并发并发优势：行锁只锁定被操作的特定行，不同事务可以同时修改同一表的不同行，极大提升了OLTP场景下的并发吞吐量，是现代关系型数据库的标准锁粒度。索引依赖：行锁的实现依赖于索引——InnoDB的行锁实际上是加在索引记录上的而非物理行本身，没有索引的列上执行更新会导致锁粒度退化。HIGHCONCURRENCY锁粒度细·开销较高ConcurrencyControlLOCKPROTOCOLS意向锁与多粒度封锁协议意向锁是轻量级的表级信号锁，用于快速判断是否存在底层锁冲突。IS/IX锁与S/X锁组合形成多粒度封锁协议，使数据库能在表级和行级之间灵活切换。IS与IX的定义：意向共享锁（IS）表示事务打算对表中某些行加S锁，意向排他锁（IX）表示打算对某些行加X锁，它们本身不阻止任何操作，只是宣告意图。核心价值：意向锁避免自底向上的锁冲突检测——有了IX锁，只需检查表级即可判断是否存在底层写冲突，无需遍历每一行。兼容性矩阵（六种组合）：IS-IS/IS-IX/IX-IX均兼容，S-IS兼容但S-IX互斥，X与所有意向锁互斥。ISIXSXIS✓✓✓✗IX✓✓✗✗S✓✗✓✗X✗✗✗✗✓兼容—可同时持有✗互斥—需等待释放意向锁之间高度兼容，仅X锁与所有锁互斥实际应用：事务在访问行之前先对表加IS或IX锁，再对目标行加S或X锁；锁升级则在行锁数量超过阈值时自动将行锁合并为表锁。CHAPTER03MVCC多版本并发控制版本链、ReadView与快照隔离DATABASE·MVCCCONCURRENCYCONTROLMVCC核心思想：读写不阻塞MVCC的核心突破在于将读从锁竞争中解放出来：写操作创建新版本而非覆盖旧版本，读操作根据可见性规则选择历史版本读取，实现读写互不阻塞。01传统锁机制的根本瓶颈—读写互斥：读操作持有S锁时写操作必须等待，高并发读写混合场景下大量事务被迫排队，吞吐量急剧下降。02MVCC的解决思路：空间换时间—每次写操作不覆盖原数据，而是创建新版本并保留旧版本，形成版本链；读操作根据可见性规则从版本链中选择合适版本读取。03两个关键性质—读者不阻塞写者（读操作不加锁）、写者不阻塞读者（写操作创建新版本），只有写写冲突才需要通过锁来解决。04隔离级别的底层机制—读未提交直接读最新版本不用MVCC，串行化用纯锁也不用MVCC，只有RC和RR两个中间隔离级别依赖MVCC。核心公式：写操作→创建新版本（版本链），读操作→选择可见版本（无锁），写写冲突→锁解决i关键洞察MVCC本质是用存储空间的代价（多版本维护）换取并发性能的提升（读写无冲突），是数据库"以空间换时间"的经典工程范式。H数据库原理MVCCINTERNALSSTORAGEENGINE隐藏字段与UndoLog版本链InnoDB通过DB_TRX_ID、DB_ROLL_PTR、DB_ROW_ID三个隐藏字段和UndoLog构建了MVCC的物理基础，多个版本通过指针串联成链。DB_TRX_ID6bytes记录最后一次修改该行的事务ID，全局递增分配，是ReadView判断版本可见性的核心依据。DB_ROLL_PTR7bytes回滚指针，指向UndoLog中该行的上一个版本记录，多个版本通过此指针形成单向链表。UndoLog复用机制不仅服务于MVCC的版本存储，还承担事务回滚和崩溃恢复职责，实现了原子性与MVCC的复用。DB_ROW_ID6bytes隐藏自增行ID，仅在表没有主键且无唯一非空索引时自动生成，用于构建聚簇索引。InnoDB版本链结构·UndoLog指针串联多版本DDATABASESYSTEMSMVCCINTERNALSReadView结构与可见性算法ReadView是MVCC的决策中枢，通过creator_trx_id、min_trx_id、max_trx_id、m_ids四个字段对版本链中每个版本进行可见性判定。ReadViewStructure01creator_trx_id创建者的事务ID02min_trx_id活跃事务最小ID03max_trx_id下一个待分配ID04m_ids活跃事务ID列表01creator_trx_id—自身可见创建该ReadView的事务自身ID，若版本的trx_id等于此值则直接可见——自己修改的数据当然自己能看见。02min/max_trx_id—边界快速判定min_trx_id是活跃事务列表中的最小ID，小于此值的版本在ReadView生成前已提交必然可见；max_trx_id是下一个待分配的事务ID，大于等于此值的版本必然不可见。03m_ids—区间内精确检查当版本trx_id落在[min,max)区间内时，需检查是否在m_ids活跃列表中：在则不可见（未提交），不在则可见（已提交）。04版本链遍历与性能隐患可见性判断沿版本链从新到旧逐版本执行，找到第一个可见版本即返回；长事务会导致链条过长影响查询性能。ISOLATIONRC与RR隔离级别的MVCC差异RC和RR在MVCC层面的唯一本质区别是ReadView的生成时机：RC每次SELECT都生成新ReadView，RR只在第一次SELECT时生成并全程复用。ReadCommitted每次读新快照RC级别下每条SELECT语句执行前都会重新生成ReadView，每次读取都能看到截至该时刻已提交的最新数据，因此同一事务内两次相同查询可能得到不同结果。RC的优势是数据新鲜度高、UndoLog清理及时，适合对一致性要求不高但追求高并发和数据实时性的OLTP场景。Non-RepeatableReadHighConcurrencyRepeatableRead事务级固定快照RR级别下事务执行第一条SELECT时生成ReadView并在整个事务生命周期内复用，无论其他事务在此期间提交了多少修改，当前事务看到的始终是同一个快照。RR的代价是长事务会阻止UndoLog清理，可能导致存储空间膨胀；同时配合Next-KeyLock解决当前读场景下的幻读问题。SnapshotReuseNext-KeyLockConcurrencyINNODBREADMODES快照读vs当前读：两种读取模式InnoDB中存在两种读取模式：快照读通过MVCC读取历史版本不加锁；当前读读取最新版本并加锁。理解两者区别是正确使用隔离级别的关键。快照读（SnapshotRead）—即普通的SELECT语句，通过MVCC机制读取ReadView可见的历史版本，全程不加任何锁，不会阻塞其他事务的读写操作。当前读（CurrentRead）—读取数据的最新版本并立即加锁，包括SELECTFORUPDATE、LOCKINSHAREMODE以及所有INSERT/UPDATE/DELETE语句。Next-KeyLock防幻读—当前读在RR级别下会使用Next-KeyLock锁定扫描范围，防止其他事务在范围内插入新行，这是InnoDB在RR级别解决幻读的关键手段。混用风险—先用快照读确认数据存在再用当前读去修改，中间可能被其他事务抢先修改导致逻辑错误，需格外小心两种模式的交替使用。DATABASEINTERNALSPostgreSQLMVCC：xmin/xmax机制PostgreSQL的MVCC不使用UndoLog，而是直接在主表中保留所有版本行，通过xmin和xmax两个系统字段标记版本的生灭，配合VACUUM机制清理过期版本。01版本标记字段：PostgreSQL的每一行元组都带有xmin和xmax两个系统字段：xmin记录插入该版本的事务ID，xmax记录删除或更新该版本的事务ID，两者共同定义了该版本的有效时间窗口。02物理存储差异：与InnoDB的版本链不同，PostgreSQL的所有版本都物理存储在同一个表中，UPDATE实际上是INSERT新版本+标记旧版本xmax，这导致表膨胀但避免了UndoLog的额外IO开销。03VACUUM清理机制：VACUUM进程负责清理不再被任何活跃事务引用的过期版本行，回收磁盘空间；AUTOVACUUM自动触发但长事务会阻止清理。04快照可见性判断：PostgreSQL的快照包含xmin、xmax和xip_list（活跃事务列表），可见性判断逻辑与InnoDB的ReadView等价但字段命名不同。DDATABASEINTERNALSCONCURRENCYCONTROLCOSTANALYSISMVCC的代价：长事务与空间膨胀MVCC并非免费午餐：长事务会阻止旧版本清理导致存储空间持续膨胀，版本链过长会降低查询性能，频繁的写操作会产生大量维护开销。长事务阻止版本清理只要一个长事务持有旧的ReadView，它所引用的所有历史版本就不能被清理，UndoLog或表空间会持续增长，严重时可能耗尽磁盘。版本链过长拖累查询ReadView的可见性判断需要沿版本链逐版本遍历，若某行被频繁更新且旧版本无法清理，单次查询可能需要遍历数十个版本。写密集场景维护开销每次UPDATE都要复制旧版本到UndoLog或插入新版本行，高频更新会导致空间快速增长，写密集场景下MVCC的维护开销不可忽视。工程应对策略设置事务超时上限避免长事务监控空间使用率与版本链长度合理配置Purge/Autovacuum参数对热点表考虑拆分或归档历史数据Chapter04死锁与高级机制等待图检测、Next-KeyLock与WAL恢复DEADLOCK死锁成因：占有并等待的循环死锁的本质是两个或多个事务形成了循环等待关系，这种僵局无法通过时间推移自行解除，必须由外部干预打破。互斥条件资源（锁）在同一时刻只能被一个事务持有，这是锁机制的基本语义，也是死锁产生的前提。占有并等待条件事务已持有至少一个锁的同时还在等待获取另一个锁，这是死锁形成的关键行为模式，C2PL正是通过破坏此条件来预防死锁。不可剥夺条件事务已持有的锁不能被系统强制收回，只能由事务自身主动释放，这意味着一旦形成循环等待就没有内部力量能打破僵局。循环等待条件存在一个事务等待环T1→T2→...→Tn→T1，其中每个事务都在等待下一个事务持有的锁，这是死锁的充分必要条件。HDATABASESYSTEMSCONCURRENCYCONTROLDEADLOCKDETECTION等待图与死锁检测算法等待图是数据库死锁检测的核心数据结构：节点代表事务，有向边代表等待关系，当图中出现环时即表明发生了死锁。等待图的构建规则当事务A因申请某资源的锁而被阻塞、且该锁当前被事务B持有时，在图中添加一条从A指向B的有向边。环检测算法对等待图执行深度优先搜索或拓扑排序，若发现回路则确认死锁存在；InnoDB在每次锁等待超时检查时触发环检测。牺牲者选择策略检测到死锁后需选择一个事务回滚以打破循环，InnoDB默认选择UndoLog量最小的事务作为牺牲者。分布式死锁检测SS2PL结合两阶段提交协议能自动将全局数据死锁转化为投票死锁并由2PC协议解决。等待图（Wait-forGraph）环检测示意CONCURRENCYCONTROLDEADLOCKSTRATEGIES死锁预防与超时回滚策略死锁处理有两条路线：预防和检测+解除。工业界普遍采用后者，因为预防措施往往以牺牲并发度为代价。预防策略：破坏必要条件一次性锁获取（C2PL）破坏占有并等待条件，但要求预知全部资源需求；锁排序协议要求所有事务按统一顺序申请锁，破坏循环等待条件。wound-wait和wait-die是基于事务时间戳的预防方案：老事务可以强制回滚新事务，这两种方案都能保证无死锁且无需预知资源需求。检测与解除：工业界主流方案超时回滚是最简单的兜底机制：事务等待锁超过innodb_lock_wait_timeout（默认50秒）即报错回滚，实现简单但响应慢。主动死锁检测是更优选择：InnoDB的死锁检测线程周期性检查等待图中的环，发现死锁立即回滚牺牲者，响应速度远快于超时机制。预防路线适合资源需求可预知的场景，但并发度受限检测+解除路线是InnoDB等主流引擎的默认选择，响应更快H数据库系统原理CONCURRENCYCONTROLMechanismNext-KeyLock：InnoDB解决幻读InnoDB在RR隔离级别下通过Next-KeyLock（记录锁+间隙锁的组合）锁定索引扫描范围，阻止其他事务在该范围内插入新行，从而在当前读场景下彻底解决幻读。锁定区间示意·WHEREid>5ANDid<101510(]左开右闭区间(5,10]—阻止修改与插入三种锁的关系：RecordLock只锁定索引上的单条记录，GapLock锁定索引记录之间的间隙，Next-KeyLock是两者的组合，锁定左开右闭区间(record,next_record]。锁定示例：索引值为1、5、10，执行WHEREid>5ANDid<10时，Next-KeyLock锁定区间(5,10]，其他事务既不能修改id=10的记录，也不能在5和10之间插入新行。生效条件：Next-KeyLock仅在当前读时生效，快照读通过MVCC的固定ReadView天然避免幻读；RC隔离级别下没有间隙锁，因此RC级别的当前读无法防止幻读。退化规则：间隙锁的范围取决于索引类型和查询条件——唯一索引等值查询退化为RecordLock，范围查询和非唯一索引才会触发完整的Next-KeyLock。H数据库系统原理RECOVERYWrite-AheadLoggingWAL预写日志与崩溃恢复WAL是事务持久性的基石：所有数据修改必须先写入日志再写入数据文件，崩溃后通过重放日志即可恢复已提交事务的修改、撤销未提交事务的影响。日志先行原则任何数据页的修改在刷盘之前，对应的日志记录必须先持久化到磁盘，这保证了即使数据页丢失也能从日志重建。崩溃恢复两阶段Redo阶段重放所有已提交事务的操作，Undo阶段撤销所有未提交事务的修改，两者共同将数据库恢复到一致状态。随机IO转顺序IO数据页的修改可能是随机的，但日志是追加写入的顺序IO，磁盘顺序写性能远高于随机写，显著提升写入吞吐。Checkpoint机制定期将内存脏页刷盘并记录检查点位置，恢复时只需从最近Checkpoint开始重放而非从头开始，大幅缩短恢复时间。CHAPTER05工程实践与总结数据库对比、调优策略与知识回顾COMPARISONDATABASE·CONCURRENCYMySQLInnoDBvsPostgreSQL并发对比MySQLInnoDB和PostgreSQL在并发控制的核心目标一致，但实现路径显著不同，理解这些差异是跨数据库开发和选型决策的关键依据。两大数据库并发控制机制对比对比维度MySQLInnoDBPostgreSQLMVCC存储UndoLog独立存储旧版本主表内保留所有版本行默认隔离级别REPEATABLEREADREADCOMMITTED读未提交支持（真正读未提交）等同于READCOMMITTED幻读解决(RR)Next-KeyLock当前读防插入SSI序列化快照隔离旧版本清理Purge线程自动清理UndoVACUUM/AUTOVACUUM回收死元组长事务影响Undo空间膨胀表膨胀+索引膨胀总结：两者各有优劣——InnoDB的UndoLog方案清理更高效但RR级别锁更重；PG的主表