做网站主要来源,磁力链最好用的搜索引擎,wordpress文章统计插件,国内大型网站域名最近在准备面试#xff0c;正把平时积累的笔记、项目中遇到的问题与解决方案、对核心原理的理解#xff0c;以及高频业务场景的应对策略系统梳理一遍#xff0c;既能加深记忆#xff0c;也能让知识体系更扎实#xff0c;供大家参考#xff0c;欢迎讨论。在数据库并发操作…
最近在准备面试正把平时积累的笔记、项目中遇到的问题与解决方案、对核心原理的理解以及高频业务场景的应对策略系统梳理一遍既能加深记忆也能让知识体系更扎实供大家参考欢迎讨论。在数据库并发操作场景中事务隔离级别是保障数据一致性的核心机制不同隔离级别对应不同的并发控制策略而 MVCC多版本并发控制则是实现部分隔离级别的关键技术。
一、数据库事务隔离级别概述
事务隔离级别定义了多个并发事务之间的相互影响程度从低到高分为四个级别不同级别在数据一致性和系统性能之间呈现不同的平衡关系。
1.1 读未提交Read Uncommitted
• 定义最低的隔离级别允许当前事务读取其他事务尚未提交的数据变更。
• 核心问题无法避免脏读、不可重复读和幻读。
• 脏读读取到其他事务未提交的“临时数据”若后续事务回滚当前读取的数据将变为无效。
• 适用场景对数据一致性要求极低仅追求极致性能的场景如临时统计查询无需精确结果实际业务中极少使用。业务场景基本都不用。
1.2 读已提交Read Committed, RC
• 定义允许当前事务读取其他事务已提交的数据变更是许多数据库的默认隔离级别之一如 Oracle。
• 核心能力可阻止脏读但仍可能出现不可重复读和幻读。
◦ 不可重复读同一事务内对同一字段多次读取结果因其他事务提交的更新操作而不同。◦ 幻读同一事务内执行相同的查询语句结果因其他事务提交的插入/删除操作而新增或减少数据行。• 实现依赖基于 MVCC 机制实现通过读取数据的“已提交版本”保障数据有效性。
1.3 可重复读Repeatable Read, RR
• 定义MySQL InnoDB 引擎的默认隔离级别确保同一事务内对同一字段的多次读取结果一致除非数据由当前事务自身修改。
• 核心能力可阻止脏读和不可重复读但仍可能出现幻读需通过额外机制解决。
• 幻读解决方案
◦ 升级隔离级别至串行化所有事务顺序执行完全避免并发干扰但会导致性能大幅下降仅适用于数据一致性要求极高且并发量低的场景。◦ MVCC 解决快照读幻读针对简单 SELECT快照读通过读取数据的历史版本非最新版本确保同一事务内查询结果一致。MySQL使用的这个来解决幻读相对锁解决幻读而言性能较高。◦ GapLock Next-KeyLock 解决当前读幻读针对 SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE 等当前读操作通过间隙锁GapLock和 next-key 锁锁定查询范围防止其他事务插入/删除数据避免幻读。1.4 串行化Serializable
• 定义最高的隔离级别强制所有事务按顺序逐个执行完全禁止并发操作。互联网项目基本没用这个的项目上线有点并发就会非常卡顿了。
• 核心能力完全符合 ACID 的隔离要求可阻止脏读、不可重复读和幻读数据一致性最强。
• 缺点极大限制并发性能仅适用于数据安全性优先于性能的极端场景如金融核心交易的关键步骤。
二、MVCC多版本并发控制机制
MVCC 是一种高效的并发控制技术主要用于实现 “读已提交RC” 和 “可重复读RR” 隔离级别通过维护数据的多个版本实现 “读 - 写”“写 - 读” 并发执行在保障数据一致性的同时提升系统性能。
2.1 MVCC 的核心原理
MVCC 的核心是为每行数据维护多个历史版本事务读取时根据自身版本号选择可见的数据版本避免直接加锁导致的并发瓶颈。其关键机制包括事务版本号
◦ 系统会为每个新启动的事务分配一个唯一的递增版本号transaction_id事务开始时的版本号即为该事务的标识。
◦ 数据行的版本号与事务版本号关联确保事务只能读取符合可见性规则的数据。隐藏列与版本链
◦ InnoDB 引擎的聚簇索引记录中默认包含两个隐藏列用于构建数据的版本链▪ trx_id存储每次修改该数据行的事务 ID记录数据的“修改者”。▪ roll_pointer存储一个指针指向该数据行的上一个历史版本存储在 Undo 日志中通过该指针可串联所有历史版本形成“版本链”。◦ 注意插入操作的 Undo 日志无 roll_pointer因为插入的数据无历史版本。Undo 日志的作用
◦ Undo 日志用于保存数据的历史版本当事务需要读取历史数据时通过 roll_pointer 从 Undo 日志中获取对应版本。
◦ 事务提交后Undo 日志不会立即删除而是根据垃圾回收机制Purge在合适时机清理确保其他事务仍能访问所需的历史版本。2.2 MVCC 的适用范围与限制
• 适用隔离级别仅支持 “读已提交RC” 和 “可重复读RR”不支持 “读未提交”需读取未提交数据与 MVCC 的“版本可见性规则”冲突和 “串行化”强制顺序执行无需 MVCC。
• 适用读操作类型
◦ 快照读简单 SELECT 语句无 FOR UPDATE、LOCK IN SHARE MODE通过 MVCC 读取历史版本无需加锁并发性能高。◦ 当前读DELETE、UPDATE、INSERT 及 SELECT ... FOR UPDATE 等操作需读取数据最新版本并加锁防止并发修改不依赖 MVCC 的版本链而是通过锁机制保障一致性。2.3 MVCC 与乐观锁的关联
MySQL 的 MVCC 本质是乐观锁的一种实现方式
• 每行数据的版本号通过 trx_id 和版本链间接体现作为乐观锁的“版本标识”。
• 事务更新数据时会检查当前数据的版本号是否与预期一致类似 “WHERE version V” 的逻辑若一致则更新并生成新版本若不一致则重试或失败避免并发冲突。
三、RC 与 RR 隔离级别的应用场景对比
RC 和 RR 均基于 MVCC 实现但因版本可见性规则不同适用场景存在显著差异四、关键总结
• 事务隔离级别从低到高为“读未提交 → 读已提交 → 可重复读 → 串行化”一致性越强性能越弱需根据业务场景权衡选择。
• MVCC 是实现 RC 和 RR 的核心技术通过版本链和 Undo 日志实现“无锁读”提升并发性能。
• RR 的幻读需通过“MVCC快照读”或“GapLock Next-KeyLock当前读”解决RC 因每次查询读最新版本幻读问题更明显。
