大学数据库系统原理《并发控制与恢复》教学课件

数据库系统原理：并发控制与恢复从并发冲突到故障恢复2026年课程导览01并发异常与事务从问题出发认识ACID02封锁与两阶段锁锁协议保证可串行化03隔离级别与MVCC一致性与性能的权衡04故障与日志WAL与检查点机制05ARIES恢复算法三阶段工业级恢复06综合与展望贯通两大核心机制01并发异常与事务并发与故障，是数据库可靠性的两大挑战并发异常破坏数据一致性数据库对象被多个事务共享，不加约束地同时读写，结果可能错乱。“并发失控，一致性无从谈起”一个转账场景事务T1将账户A的500元转入账户B事务T2同时读取两个账户余额生成报表串行vs并发串行：报表读到转账前或转账后的完整状态并发交叉：T2可能读到「A已扣款、B尚未加款」的中间状态“这种并发引发的数据不一致，破坏了数据库一致性要求。正确并发的结果必须等价于某种串行执行的结果。”三类并发异常逐一辨析并发失控表现为三类典型异常，共同点是事务间相互干扰，区别在于干扰对象不同。三类三类并发异常：问题·成因·干扰对象脏读T1修改元组未提交，T2读到该值；T1回滚后，T2读到的数据从未真正生效。干扰对象脏读干扰的是单值不可重复读T1两次读取同一元组，期间T2修改或删除该元组并提交，两次结果不一致。干扰对象不可重复读干扰的是同一行幻读T1按谓词条件读取一组元组，T2插入符合条件的新元组并提交；T1再次查询，结果集行数变化，像「凭空多出来」。干扰对象幻读干扰的是满足条件的集合事务的ACID性质事务是一组逻辑上不可再分的操作序列，其可靠性边界由

ACID

四条性质界定。ACID四条性质4项原子性操作要么全部成功，要么全部不生效，不存在半途而废的中间状态一致性事务执行前后，数据库都处于合法状态隔离性并发事务彼此透明，仿佛各自独占数据库持久性事务一旦提交，结果即使遭遇故障也不丢失三类并发异常侵犯的正是

隔离性——失控调度让事务看到了对方的未提交状态或中间结果。冲突操作与可串行化调度冲突操作定义与判定分属不同事务、作用于同一对象，且至少有一个是写操作——顺序不可交换。全为读操作则不冲突，可交换。可串行化调度正确性标准交叉执行的结果，与某串行顺序执行完全一致。交叉执行却保持串行正确性，是并发控制的最低标准。冲突图判定结构·判据·意义事务为顶点，冲突先后关系为有向边。无环

⇔

冲突可串行化。该工具为下一章用封锁构造可串行化调度奠定基础。S锁与X锁控制读写互斥锁的相容矩阵已持有\申请SXS✓

相容✗

互斥X✗

互斥✗

互斥加锁须在访问对象之前执行，从操作层面消除并发写与读写冲突。遗留问题：仅「随手加锁、用完即放」不足以保证整体调度可串行化——释放锁的时机若不受约束，事务间仍可能形成错误交错。这正是两阶段锁协议要解决的精确问题。S锁（共享锁）用于读操作，多个事务可同时对同一对象加S锁并发读取X锁（排他锁）用于写操作，持有期间其他事务既不能加S锁也不能加X锁，必须等待释放两阶段锁协议的两个阶段01增长阶段→只许加锁，禁止释放任何锁。02收缩阶段→只许放锁，禁止申请新锁。03本质与效果→两阶段锁：所有加锁操作先于所有解锁操作。本质：所有加锁操作先于所有解锁操作效果：收缩一旦开始，事务不再引入新冲突顺序，避免循环依赖实践：严格两阶段锁（SS2PL）将全部锁持有到提交或回滚时一次性释放，消除级联回滚风险事务调度可串行化的保证凡遵守2PL的调度，冲突图必无环，因而是冲突可串行化的。2PL保证正确性，但牺牲并发度——正确与高效的取舍由此展开。小结：2PL是冲突可串行化的充分非必要条件；引出死锁处理与MVCC的优化动机。充分而非必要充分凡遵守2PL的调度，冲突图必无环，因而是冲突可串行化的。逆否若存在优先图环路，必然违反「加锁先于解锁」的约束。反例：可串行却无法由2PL得到场景T1写x后提交，T2读x，T3与T1对y有先后——该交错本身可串行化。阻塞但2PL下T2必须等待T1释放x的锁，阻塞顺序与理想调度不同。代价：牺牲并发度取舍2PL保证「正确」，不保证「最优并发度」。动因部分本可并行的机会被放弃，这正是死锁与

MVCC

等改进方案的动因。死锁的产生与等待图检测两阶段锁保证正确性，却可能让事务互相死锁。两阶段锁保证正确性，却可能让事务互相卡死：T1持有x等y，T2持有y等x，双方互不相让，系统停滞。01问题一死锁成因T1持有x等y，T2持有y等x，双方互不相让，系统停滞。02检测方法等待图检测以事务为顶点，T1因等待T2的锁而阻塞，就从T1向T2连一条有向边图中出现环，即判定死锁。03解决方案工程应对超时机制：等待超过阈值即判可能死锁，选一个事务作牺牲者，中断回滚打破循环热点后置：最热点记录的访问放到事务最后，缩短持锁时间固定顺序：并发SQL按固定对象访问顺序执行，从源头避免循环等待四级隔离级别的递进关系SQL标准定义四个隔离级别，从低到高依次递进。理解这四级递进，是选择事务配置、权衡一致性与性能的前提。读未提交最低级别能看到对方尚未提交的修改并发性能最好、一致性最弱读已提交第二级只能看到已提交数据可重复读第三级同一事务内重复读取结果一致可串行化最高级别并发执行效果完全等价于串行执行权衡一致性与性能级别越低，中间状态越多、吞吐越高级别越高，隔离越彻底、锁等待越多隔离级别与异常对应矩阵隔离级别脏读不可重复读幻读读未提交可能可能可能读已提交阻止可能可能可重复读阻止阻止可能可串行化阻止阻止阻止隔离每升一级，能阻止的异常便多一类，并发代价也同步上升——这正是「隔离越强、并发越受限」的具体体现。各数据库默认隔离级别差异MySQLInnoDB默认·可重复读默认可重复读，靠

Next-KeyLock（行锁+间隙锁）基本规避标准定义下的典型幻读。PostgreSQL/Oracle默认·读已提交默认

读已提交，隔离更弱、并发更高。实现与选型机制·权衡·场景隔离级别是SQL标准概念，各库用锁或多版本机制自行实现。MySQL可重复读下：读走快照读，写走当前读并加锁，二者配合才防幻读。金融强一致场景选可重复读或更高；统计日志可容忍轻微不一致，读已提交更合适。盲目上可串行化会引发大量锁等待。MVCC的核心思想与价值MVCC通过版本控制，让读写并行执行，无需长时间等待锁释放。MVCC是高并发读多写少场景下提升性能的关键机制。三个价值维度性能读不阻塞写、写不阻塞读，系统吞吐显著提升一致性可见性规则确保事务看到符合其隔离级别的数据视图锁开销锁竞争从操作级降到事务级电商场景用户A修改商品库存时，用户B仍可读到修改前的库存值完成下单，非阻塞并发提升系统响应能力。版本链与ReadView可见性判断MVCC依赖两个关键结构：版本链

与ReadView。问题引入同一行数据被多个事务并发修改时，如何判断哪个版本对当前事务可见？MVCC用版本链与ReadView给出答案。核心要点版本链保存行的所有历史版本，ReadView决定可见性——ReadView的生成时机，正是可重复读与读已提交隔离效果的根源。版本链DB_TRX_ID隐藏字段，记录最后修改该行的事务IDDB_ROLL_PTR隐藏字段，指向回滚段中的历史版本形成链修改时旧版本压入undolog，形成版本链ReadView可见性规则版本事务ID=当前事务ID→可见（自己改的）版本事务ID<最小活跃事务ID→可见（已提交事务改的）版本事务ID落在活跃事务列表中→不可见，沿回滚指针向前查找更早版本隔离级别差异的根源可重复读ReadView在事务首次读取时生成，全程复用读已提交每次查询重新生成ReadView当前读与快照读的分工MVCC不取代锁，而是与锁分工协作，关键在区分两种读。SELECT也会加锁吗？——取决于走哪条读路径当前读加锁，快照读无锁快照读普通SELECT，读事务启动时的历史版本结果：不加锁当前读SELECT…FORUPDATE、UPDATE、DELETE必须读最新版本，需要加锁组合方案写走2PL：保证冲突可串行化读走MVCC：快照避免加锁场景选择锁机制：直接阻止冲突访问，适合更新频繁、冲突多的场景MVCC：版本控制让快照读不阻塞，适合读多写少的场景MVCC与2PL的取舍权衡2PL直接但易阻塞，MVCC无锁读但存版本，工程上组合使用2PL·两阶段锁2PL：直接但易阻塞锁申请与释放直接管理并发，实现简单实现简单，锁管理器加锁表即可支撑更新频繁、冲突多的场景更直接有效高并发下易锁等待甚至死锁，拖累响应速度MVCC·多版本并发控制MVCC：无锁读但存版本读不阻塞写、写不阻塞读，读写并行优势显著代价是存储多个数据版本，undolog带来额外读写与管理负担不及时经purge线程回收旧版本，性能随版本链变长下降快照隔离之下，读无需加锁即可获得一致性视图系统故障的分类与影响并发控制解决事务间干扰，而系统可能在任何时刻崩溃——故障恢复是数据库必须面对的又一类挑战。系统可能在任何时刻崩溃，故障恢复是数据库必须面对的又一类挑战。按影响范围，可将系统故障分为三类。三类故障的共同威胁：已提交事务的修改可能尚未落盘而丢失，未提交事务的修改却可能已写入磁盘，使数据库陷入不一致状态。恢复机制的任务，正是让系统重启后回到一致状态。事务故障逻辑错误或死锁被中断，只影响该事务本身，可回滚处理。系统故障断电、OS崩溃致系统停止，内存数据丢失，磁盘数据仍在，需依据日志恢复。介质故障存储介质损坏，磁盘数据可能丢失，恢复难度最大，需借助后备副本与日志重做。WAL日志先行的核心原则“任何数据修改前，变更记录必须先写入持久化日志，之后才允许改数据文件。”InnoDB落地路径01页面修改→发生在

BufferPool

内存页02变更写入→写入

redologbuffer03提交刷盘→按策略执行04延迟写回→由后台刷脏线程执行核心口诀：先记账，后干活双重价值可靠性崩溃后可依据日志重放或回滚，守住原子性与持久性性能数据文件修改是随机写，日志追加是顺序写，顺序I/O远快于随机I/Oredolog与刷盘策略三档“理解这个时间差，就理解了持久性的工程实现。”—刷盘策略的本质档位1·innodb_flush_log_at_trx_commit=1每次提交都落盘提交即

fsync，最安全、不丢已提交数据，写入延迟最高。

金融支付等核心业务采用›档位2·innodb_flush_log_at_trx_commit=2写入OS缓存提交时写入

OS缓存但不强制fsync。

断电可能丢失缓存数据›档位0·innodb_flush_log_at_trx_commit=0提交时不写日志后台线程

每秒刷一次，性能最好。

崩溃至多丢失一秒数据“理解这个时间差，就理解了持久性的工程实现。”—三档本质：「提交成功」与「真正落盘」的时间差WAL落地为redologInnoDB持久性基石循环日志文件：记录物理数据页的字节级修改；以单调递增的

LSN

标识顺序。最安全延迟最高兼容性能性能最好最多丢1秒检查点缩短恢复时间检查点与WAL分工明确：日志写多少由WAL决定，恢复从哪开始重放由检查点决定。问题：每次崩溃都从第一条redolog重放？——检查点充当恢复「存档点」，其后恢复只需从该点开始重放即可。检查点与WAL分工明确：一个决定「日志写多少」，一个决定「恢复从哪开始重放」，共同把恢复时间控制在可接受范围。InnoDB模糊检查点脏页集中在BufferPool，分批刷脏落盘脏页集中在

BufferPool，分批刷脏仅当某

LSN

之前所有脏页落盘后，检查点才推进到该位置推进速度决定崩溃后需重放的

redolog数量PostgreSQL触发参数通过时间间隔与WAL积累量触发检查点checkpoint_timeout：时间间隔参数，周期触发检查点max_wal_size：WAL积累量阈值，达到后触发检查点ARIES的历史重建哲学恢复是历史的忠实重建，而非对故障时刻状态的猜测性修补。重复历史Redo重复所有已提交事务的全部修改逆序撤销Undo按操作执行逆序逐条撤销未提交事务可重入中途再次崩溃后重启可继续恢复，不必从头开始问题各自为