尧图建网站 尧图建网站 YAOTU WEB BUILD 免费咨询
ARTICLE DETAIL

资讯详情

深耕网站建设与建站编程的一线实战洞察。

【MYSQL】MYSQL学习的一大重点:事务(中)- 隔离性与一致性

【MYSQL】MYSQL学习的一大重点:事务(中)- 隔离性与一致性 个人主页艾莉丝努力练剑❄专栏传送门《C语言》《数据结构与算法》《C/C干货分享学习过程记录》《Linux操作系统编程详解》《笔试/面试常见算法从基础到进阶》《Python干货分享》⭐️为天地立心为生民立命为往圣继绝学为万世开太平 艾莉丝的简介文章目录0 ~ 隔离性与一致性知识图谱1 ~ 隔离性基础认知1.1 数据库三类并发场景1.2 隔离性的本质定义1.3 隔离级别的设计逻辑2 ~ 四种事务隔离级别详解2.1 读未提交Read Uncommitted, RU2.2 读提交Read Committed, RC2.3 可重复读Repeatable Read, RR2.4 串行化Serializable3 ~ 隔离级别的查看与设置3.1 全局与会话隔离级别差异3.2 标准 SQL 语法查看隔离级别设置隔离级别4 ~ 并发异常与对应关系4.1 三类读异常4.1.1 脏读Dirty Read4.1.2 不可重复读Non-Repeatable Read4.1.3 幻读Phantom Read4.2 两类更新丢失4.3 隔离级别 - 问题对照表5 ~ 隔离性实现原理基础5.1 MVCC多版本并发控制5.2 锁机制基础6 ~ 事务一致性Consistency6.1 一致性的定义6.2 AID 与 C 的因果关系结尾0 ~ 隔离性与一致性知识图谱MySQL事务隔离性与一致性 ├─1~隔离性基础认知 │ ├─1.1数据库三类并发场景 │ ├─1.2隔离性的本质定义 │ └─1.3隔离级别的设计逻辑 ├─2~四种事务隔离级别详解 │ ├─2.1读未提交Read Uncommitted │ ├─2.2读提交Read Committed │ ├─2.3可重复读Repeatable Read │ └─2.4串行化Serializable ├─3~隔离级别的查看与设置 │ ├─3.1全局与会话隔离级别差异 │ └─3.2标准SQL语法 ├─4~并发异常与对应关系 │ ├─4.1三类读异常 │ │ ├─ 脏读 │ │ ├─ 不可重复读 │ │ └─ 幻读 │ ├─4.2两类更新丢失 │ └─4.3隔离级别-问题对照表 ├─5~隔离性实现原理基础 │ ├─5.1MVCC多版本并发控制 │ └─5.2锁机制基础 ├─6~事务一致性Consistency │ ├─6.1一致性的定义 │ └─6.2AID与C的因果关系 └─7~原笔记技术审计与纠错1 ~ 隔离性基础认知1.1 数据库三类并发场景读 - 读无任何并发安全问题无需并发控制读写存在线程安全问题会引发脏读、不可重复读、幻读三类隔离性异常写写存在线程安全问题会引发更新丢失问题第一类、第二类更新丢失1.2 隔离性的本质定义核心定义事务在执行过程中应当尽可能不受其他并发事务的干扰每个事务只能看到符合自身时间线的数据视图底层逻辑事务具备「执行前 - 执行中 - 执行后」完整生命周期隔离性保证事务执行阶段的内部操作不会被外部事务随意观测是事务原子性的外在保障类比理解每个事务有独立的时间线只能观测到自身生命周期内可见的数据如同人无法看到自己出生前的完整历史1.3 隔离级别的设计逻辑核心矛盾隔离严格程度与数据库并发性能成反比 —— 隔离越严格数据安全性越高但并发吞吐越低设计原则数据库不替业务做决策只提供多级隔离方案由开发者根据业务场景在「数据安全」与「并发性能」之间选择平衡点2 ~ 四种事务隔离级别详解2.1 读未提交Read Uncommitted, RU定义所有事务都可以看到其他并发事务尚未提交的执行结果实现本质几乎无锁读写操作互不阻塞存在问题脏读、不可重复读、幻读全部存在生产建议实际生产环境严禁使用仅用于原理验证实验现象特征事务 A 执行 insert/update 且未 commit 时事务 B 可直接查询到修改后的数据2.2 读提交Read Committed, RC定义一个事务只能看到其他已经提交的事务所做的修改行业地位Oracle、PostgreSQL 等大多数数据库的默认隔离级别解决问题彻底解决脏读遗留问题仍存在不可重复读、幻读现象特征事务 A 修改数据并 commit 后处于执行中的事务 B 再次查询即可看到最新数据事务 A 未 commit 时事务 B 完全看不到修改2.3 可重复读Repeatable Read, RR定义确保同一个事务在整个执行周期内多次执行相同查询语句得到的数据行完全一致行业地位MySQL InnoDB 引擎的默认隔离级别解决问题彻底解决脏读、不可重复读幻读说明标准 SQL 规范中的 RR 级别仍存在幻读问题MySQL InnoDB 做了增强快照读场景通过事务级快照避免幻读当前读加锁读场景通过 Next-Key 锁间隙锁 行锁防止幻读现象特征事务 A 完成增删改并提交后只要事务 B 未结束事务 B 内的查询始终看到事务启动时的快照数据2.4 串行化Serializable定义事务最高隔离级别强制所有事务按到来顺序串行执行彻底消除并发冲突实现方式普通 SELECT 会被隐式转为共享锁读增删改加排他锁读写互斥、写写互斥解决问题彻底解决脏读、不可重复读、幻读所有异常弊端并发性能极差极易出现锁等待超时与死锁生产建议实际生产环境基本不使用现象特征事务 A 开启并查询数据后事务 B 对同表执行增删改会被阻塞直到事务 A 提交或回滚3 ~ 隔离级别的查看与设置3.1 全局与会话隔离级别差异全局隔离级别global作为所有新建会话的默认配置修改后仅对后续新建立的连接生效不影响当前已存在的连接会话隔离级别session仅对当前数据库连接生效修改后立即生效不影响其他任何连接初始化规则新建数据库连接时会自动拷贝全局隔离级别作为当前会话的初始隔离级别3.2 标准 SQL 语法查看隔离级别-- 查看全局隔离级别SELECTglobal.tx_isolation;-- 查看当前会话隔离级别SELECTsession.tx_isolation;-- 简写形式默认查看会话隔离级别SELECTtx_isolation;兼容性说明MySQL 8.0 版本中tx_isolation变量已被废弃替换为transaction_isolation5.7 版本中使用tx_isolation会触发警告开发与面试中需注意版本差异。设置隔离级别-- 设置当前会话隔离级别SETSESSIONTRANSACTIONISOLATIONLEVEL{READUNCOMMITTED|READCOMMITTED|REPEATABLEREAD|SERIALIZABLE};-- 设置全局隔离级别SETGLOBALTRANSACTIONISOLATIONLEVEL{READUNCOMMITTED|READCOMMITTED|REPEATABLEREAD|SERIALIZABLE};4 ~ 并发异常与对应关系4.1 三类读异常4.1.1 脏读Dirty Read定义一个事务在执行过程中读取到了另一个并发事务尚未提交的修改数据本质读取了事务的中间状态数据若对方事务回滚该数据即为无效脏数据发生级别仅读未提交级别4.1.2 不可重复读Non-Repeatable Read定义同一个事务内多次执行相同查询由于其他并发事务提交了修改 / 删除操作导致两次查询的数据值不一致侧重点针对数据的修改update与删除delete聚焦于数据内容的变化发生级别读未提交、读提交级别4.1.3 幻读Phantom Read定义同一个事务内多次执行相同范围查询由于其他并发事务提交了插入操作导致两次查询的记录行数不一致侧重点针对数据的新增insert聚焦于记录数量的变化发生级别标准 SQL 下读未提交、读提交、可重复读均存在MySQL InnoDB 的 RR 级别做了增强优化4.2 两类更新丢失第一类更新丢失回滚覆盖一个事务回滚时覆盖了其他并发事务已经提交的更新高隔离级别已自动避免第二类更新丢失提交覆盖一个事务提交时覆盖了其他并发事务已经提交的更新所有数据库隔离级别都无法自动避免需业务层通过乐观锁或悲观锁解决重要结论MVCC 无法解决更新丢失问题写写冲突必须通过锁机制处理4.3 隔离级别 - 问题对照表隔离级别脏读不可重复读幻读实现方式并发性能读未提交存在存在存在几乎无锁最高读提交不存在存在存在MVCC语句级快照高可重复读InnoDB不存在不存在基本不存在 *MVCC事务级快照 Next-Key 锁中串行化不存在不存在不存在全量加锁串行执行最低*注标准 SQL 规范中 RR 级别存在幻读MySQL InnoDB 的 RR 级别在快照读场景无幻读当前读场景通过 Next-Key 锁防止幻读。5 ~ 隔离性实现原理基础5.1 MVCC多版本并发控制定位解决读写冲突的无锁并发控制方案实现读操作不阻塞写、写操作不阻塞读大幅提升数据库并发读写性能核心思想为事务分配单向增长的事务 ID为每次数据修改保存关联事务 ID 的版本读操作只读事务开始前的数据库快照不与写操作竞争锁能力边界可解决脏读、不可重复读无法单独解决幻读与更新丢失三大核心前提三个记录隐藏字段DB_TRX_ID6 字节最近一次创建或修改该记录的事务 IDDB_ROLL_PTR7 字节回滚指针指向该记录的上一个历史版本数据存储于 undo logDB_ROW_ID隐藏主键表无显式主键时自动生成undo 日志维护数据的历史版本链支撑事务回滚与 MVCC 快照读取Read View读视图判断当前事务可见哪些数据版本的规则集RC 与 RR 的核心差异就在于 Read View 的生成时机5.2 锁机制基础隔离性本质通过锁实现不同隔离级别对应不同的锁策略常见锁类型表锁、行锁、读锁共享锁、写锁排他锁、间隙锁GAP、Next-Key 锁间隙锁 行锁读写并发场景读走 MVCC 无锁快照写加行锁读写互不阻塞写写并发场景必须加锁互斥保证同一行数据同一时间只有一个事务执行修改6 ~ 事务一致性Consistency6.1 一致性的定义核心定义事务执行的结果必须使数据库从一个一致性状态变迁到另一个一致性状态数据库只包含成功提交的结果时处于一致性状态本质属性一致性是业务层面的目标而非纯技术属性数据库仅提供技术支撑最终的数据一致性必须由正确的业务逻辑保障典型示例转账场景中转账前后两个账户的总金额保持不变即为业务一致性6.2 AID 与 C 的因果关系结论原子性Atomicity、隔离性Isolation、持久性Durability是「因」一致性Consistency是「果」补充说明仅靠数据库技术无法完全保证一致性必须结合正确的业务逻辑才能实现数据的最终一致。结尾uu们本文的内容到这里就全部结束了艾莉丝在这里再次感谢您的阅读艾莉丝努力练剑C/C Linux 底层探索者 | 一个正在努力练剑的技术博主【关注】跟随我一起深耕技术领域见证每一次成长。❤️【点赞】让优质内容被更多人看见让知识传递更有力量。⭐【收藏】把核心知识点存好在需要时随时查、随时用。【评论】分享你的经验或疑问评论区一起交流避坑不要忘记给博主“一键四连”哦“今日练剑达成”“技术之路难免有困惑但同行的人会让前进更有方向。”结语希望对学习Linux相关内容的uu有所帮助不要忘记给博主“一键四连”哦往期回顾【MYSQL】MYSQL学习的一大重点事务上- 原子性与持久性博主在这里放了一只小狗大家看完了摸摸小狗放松一下吧૮₍ ˶ ˊ ᴥ ˋ˶₎ა
返回列表