室内设计有哪些网站,网页平面设计要学什么,重庆妇科医院排名前三,东莞做一个企业网站要多少钱#x1f38d;目录 ⛳ MVCC 原理详解#x1f43e; 一、事务回顾#x1f4d0; 1.1、什么是数据库事务#xff0c;为什么要有事务#x1f389; 1.2、事务包括哪几个特性#xff1f;#x1f38d; 1.3、事务并发存在的问题1.3.1、脏读1.3.2、不可重复读1.3.3、幻读 #x1f… 目录 ⛳ MVCC 原理详解 一、事务回顾 1.1、什么是数据库事务为什么要有事务 1.2、事务包括哪几个特性 1.3、事务并发存在的问题1.3.1、脏读1.3.2、不可重复读1.3.3、幻读 1.4 四大隔离级别1.4.1 读未提交1.4.2 读已提交1.4 3 可重复读1.4.4 串行化 1.5、MySQL数据库是如何保证事务的隔离性的呢 二、什么是 MVCC 三、MVCC 实现的关键知识点 3.1、事务版本号 3.2、隐式字段 3.3、undo log 3.4、版本链 3.5、快照和当前读 3.6、Reader View 四、MVCC的演示过程 ⛳ MVCC 原理详解 一、事务回顾 1.1、什么是数据库事务为什么要有事务
事务由一个有限的数据库操作序列构成这些操作要么全部执行,要么全部不执行是一个不可分割的工作单位。 假如 A 转账给 B 100 元先从 A 的账户里扣除 100 元再在 B 的账户上加上 100 元。如果扣完 A 的 100 元后还没来得及给 B 加上银行系统异常了最后导致 A 的余额减少了B 的余额却没有增加。所以就需要事务将 A 的钱回滚回去就是这么简单。 为什么要有事务呢 就是为了保证数据的最终一致性。 1.2、事务包括哪几个特性
事务四个典型特性即 ACID原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability。
原子性事务作为一个整体被执行包含在其中的对数据库的操作要么全部都执行要么都不执行。一致性指在事务开始之前和事务结束以后数据不会被破坏假如 A 账户给 B 账户转 10 块钱不管成功与否A 和 B 的总金额是不变的。隔离性多个事务并发访问时事务之间是相互隔离的一个事务不应该被其他事务干扰多个并发事务之间要相互隔离。持久性表示事务完成提交后该事务对数据库所作的操作更改将持久地保存在数据库之中。 1.3、事务并发存在的问题
事务并发会引起脏读、不可重复读、幻读问题
1.3.1、脏读 如果一个事务读取到了另一个未提交事务修改过的数据我们就称发生了脏读现象。 假设现在有两个事务 A、B
假设现在 Jay 的余额是 100 事务 A 正在准备查询 Jay 的余额事务 B 先扣减 Jay 的余额扣了 10 但是还没提交最后 A 读到的余额是 90 即扣减后的余额 **脏读**因为事务 A 读取到事务 B 未提交的数据这就是脏读。
1.3.2、不可重复读 同一个事务内前后多次读取读取到的数据内容不一致 假设现在有两个事务 A 和 B
事务 A 先查询 Jay 的余额查到结果是 100这时候事务 B 对 Jay 的账户余额进行扣减扣去 10 后提交事务事务 A 再去查询 Jay 的账户余额发现变成了 90 不可重复读事务 A 被事务 B 干扰到了在事务 A 范围内两个相同的查询读取同一条记录却返回了不同的数据这就是不可重复读。
1.3.3、幻读 如果一个事务先根据某些搜索条件查询出一些记录在该事务未提交时另一个事务写入了一些符合那些搜索条件的记录如 insert、delete、update就意味着发生了幻读。 假设现在有两个事务 A、B
事务 A 先查询 id 大于 2 的账户记录得到记录 id2 和 id3 的两条记录这时候事务 B 开启插入一条 id4 的记录并且提交了事务 A 再去执行相同的查询却得到了 id2,3,4 的 3 条记录了。 **幻读**事务 A 查询一个范围的结果集另一个并发事务 B 往这个范围中插入新的数据并提交事务然后事务 A 再次查询相同的范围两次读取到的结果集却不一样了这就是幻读。 1.4 四大隔离级别 问题四大隔离级别都会存在哪些并发问题 为了解决并发事务存在的脏读、不可重复读、幻读等问题数据库大叔设计了四种隔离级别。分别是读未提交读已提交可重复读串行化Serializable。 Oracle 支持的 2 种事务隔离级别READ COMMITED, SERIALIZABLE。 Oracle 默认的事务隔离级别为: READ COMMITED 。Mysql 支持 4 种事务隔离级别。Mysql 默认的事务隔离级别为: REPEATABLE READ。
1.4.1 读未提交
读未提交隔离级别只限制了两个数据不能同时修改但是修改数据的时候即使事务未提交都是可以被别的事务读取到的这级别的事务隔离有脏读、不可重复读、幻读的问题
1.4.2 读已提交
读已提交隔离级别当前事务只能读取到其他事务提交的数据所以这种事务的隔离级别解决了脏读问题但还是会存在不可重复读、幻读问题
1.4 3 可重复读
可重复读隔离级别限制了读取数据的时候不可以进行修改所以解决了不可重复读的问题但是读取范围数据的时候是可以插入数据所以还会存在幻读问题
1.4.4 串行化
事务最高的隔离级别在该级别下所有事务都是进行串行化顺序执行的。可以避免脏读、不可重复读与幻读所有并发问题。但是这种事务隔离级别下事务执行很耗性能。 1.5、MySQL数据库是如何保证事务的隔离性的呢
数据库是通过加锁来实现事务的隔离性的。这就好像如果你想一个人静静不被别人打扰你就可以在房门上加上一把锁。
加锁确实好使可以保证隔离性。比如串行化隔离级别就是加锁实现的。但是频繁的加锁导致读数据时没办法修改修改数据时没办法读取大大降低了数据库性能。
那么如何解决加锁后的性能问题的
答案就是,MVCC 多版本并发控制它实现读取数据不用加锁可以让读取数据同时修改。修改数据时同时可读取。 二、什么是 MVCC MVCC 体现了两种思想 MVCC 是 写时复制copy on writer思想的一种体现MVCC 是 以空间换时间 思想的一种体现 MVCC Muti-Version Concurrency Control 多版本并发控制是用来在数据库中控制并发的⽅法实现对数据库的并发访问⽤的就是⼀种写时复制的思想的应⽤。在MySQL中MVCC只在读取已提交Read Committed和可重复读Repeatable Read两个事务级别下有效。其是通过Undo⽇志中的版本链和ReadView⼀致性视图来实现的。MVCC就是在多个事务同时存在时SELECT语句找寻到具体是版本链上的哪个版本然后在找到的版本上返回其中所记录的数据的过程。
⾸先需要知道的是在MySQL中会默认为我们的表后⾯添加三个隐藏字段
DB_ROW_ID⾏IDMySQL的B树索引特性要求每个表必须要有⼀个主键。如果没有设置的话会⾃动寻找第⼀个不包含NULL的唯⼀索引列作为主键。如果还是找不到就会在这个DB_ROW_ID上⾃动⽣成⼀个唯⼀值以此来当作主键该列和MVCC的关系不⼤DB_TRX_ID事务ID记录的是当前事务在做INSERT或UPDATE语句操作时的事务IDDELETE语句被当做是UPDATE语句的特殊情况后⾯会进⾏说明DB_ROLL_PTR回滚指针通过它可以将不同的版本串联起来形成版本链。相当于链表的next指针。 数据库中同时存在多个版本的数据并不是整个数据库的多个版本而是某一条记录的多个版本同时存在在某个事务对其进行操作的时候需要查看这一条记录的隐藏列事务版本 id比对事务 id 并根据事物隔离级别去判断读取哪个版本的数据。 三、MVCC 实现的关键知识点 3.1、事务版本号 事务每次开启前都会从数据库获得一个自增长的事务ID可以从事务ID判断失误的执行先后顺序。这就是事务版本号。 3.2、隐式字段
对于 InnoDB 存储引擎每一行记录都有两个隐藏列 trx_id、roll_pointer如果表中没有主键和非 NULL 唯一键时则还会有第三个隐藏的主键列 row_id。 3.3、undo log
undo log回滚日志用于记录数据被修改前的信息。在表记录修改之前会先把数据拷贝到 undo log 里如果事务回滚即可以通过 undo log 来还原数据。 直接上有种后悔药叫undo log 可以这样认为当 delete 一条记录时undo log 中会记录一条对应的 insert 记录当 update 一条记录时它记录一条对应相反的 update 记录。
undo log 有什么用途呢
事务回滚时保证原子性和一致性。用于 MVCC 快照读。 3.4、版本链
多个事务并行操作某一行数据时不同事务对该行数据的修改会产生多个版本然后通过回滚指针roll_pointer连成一个链表这个链表就称为版本链。如下 其实通过版本链我们就可以看出事务版本号、表格隐藏的列和 undo log 它们之间的关系。我们再来小分析一下。 假设现在有一张 core_user 表表里面有一条数据,id 为 1名字为孙权 现在开启一个事务 A对 core_user 表执行update core_user set name 曹操 where id1,会进行如下流程操作 首先获得一个事务 ID100把 core_user 表修改前的数据,拷贝到 undo log修改 core_user 表中id1 的数据名字改为曹操把修改后的数据事务 Id101 改成当前事务版本号并把 roll_pointer 指向 undo log 数据地址。 3.5、快照和当前读
快照读 读取的是记录数据的可见版本有旧的版本。不加锁,普通的 select 语句都是快照读,如
select * from core_user where id 2;当前读读取的是记录数据的最新版本显式加锁的都是当前读
select * from core_user where id 2 for update;
select * from account where id2 lock in share mode;3.6、Reader View
Read View 是什么呢 它就是事务执行 SQL 语句时产生的读视图。实际上在 innodb 中每个 SQL 语句执行前都会得到一个 Read View。
Read View 有什么用呢 它主要是用来做可见性判断的即判断当前事务可见哪个版本的数据~
Read View 是如何保证可见性判断的呢我们先看看 Read view 的几个重要属性
m_ids:当前系统中那些活跃(未提交)的读写事务 ID, 它数据结构为一个 List。min_limit_id:表示在生成 Read View 时当前系统中活跃的读写事务中最小的事务 id即 m_ids 中的最小值。max_limit_id:表示生成 Read View 时系统中应该分配给下一个事务的 id 值。creator_trx_id: 创建当前 Read View 的事务 ID 其中min_id指向ReadView中未提交事务数组中的最⼩事务ID⽽max_id指向ReadView中的已经创建的最⼤事务ID
如果落在绿⾊区间DB_TRX_ID min_id这个版本⽐min_id还⼩事务ID是从⼩往⼤顺序⽣成的说明这个版本在SELECT之前就已经提交了所以这个数据是可⻅的。或者这⾥是短路或前⾯条件不满⾜才会判断后⾯这个条件这个版本的事务本身就是当前SELECT语句所在事务的话也是⼀样可⻅的如果落在红⾊区间DB_TRX_ID max_id表示这个版本是由将来启动的事务来⽣成的当前还未开始那么是不可⻅的如果落在⻩⾊区间min_id DB_TRX_ID max_id这个时候就需要再判断两种情况 如果这个版本的事务ID在ReadView的未提交事务数组中表示这个版本是由还未提交的事务⽣成的那么就是不可⻅的如果这个版本的事务ID不在ReadView的未提交事务数组中表示这个版本是已经提交了的事务⽣成的那么是可⻅的。
如果在上述的判断中发现当前版本是不可⻅的那么就继续从版本链中通过回滚指针拿取下⼀个版本来进⾏上述的判断。 四、MVCC的演示过程
下⾯通过⼀个示例来具体演示MVCC的执⾏过程假设是在可重复读事务级别下当前account表中已经有了⼀条初始数据id1,namemonkey 从左往右分别是五个事务从上到下是时刻点。其中在第2和3时刻点中事务100和事务200这⾥两个事务之间相差100只是为了更加⽅便去看正常来说下个事务的ID是以1的⽅式来创建的分别执⾏了⼀条UPDATE语句这两条语句并⽆实际作⽤只是为了⽣成事务ID的所以在下⾯的MVCC执⾏过程中就不分析这两条语句所带来的影响了我们只研究account表。⽽其中最后两个事务我是注明没有事务ID的。因为事务ID是执⾏⼀条更新操作增删改的语句后才会⽣成这也是事务100和事务200要先执⾏5⼀条更新语句的意义并不是开启事务的时候就会⽣成。最后两个事务中可以看到就是执⾏了⼀些SELECT语句⽽已所以它们并没有事务ID。
⾸先来看⼀下初始状态时的版本链和ReadViewReadView此时还未⽣成 其中事务1在account表中创建了⼀条初始数据。 之后在第1时刻点五个事务分别开启了事务如上所说这个时候还没有⽣成事务ID。
在第2时刻点第⼀个事务执⾏了⼀条UPDATE语句⽣成了事务ID为100。
在第3时刻点第⼆个事务执⾏了⼀条UPDATE语句⽣成了事务ID为200。
在第4时刻点第三个事务执⾏了⼀条UPDATE语句将account表中id为1的name改为了monkey301。同时⽣成了事务ID为300。
在第5时刻点事务300也就是上⾯的事务执⾏了commit操作。
在第6时刻点第四个事务执⾏了⼀条SELECT语句想要查询⼀下当前id为1的数据如上所说该事务没有⽣成事务ID。此时的版本链和ReadView如下 因为在第5时刻点事务300已经commit了所以ReadView的未提交事务数组中不包含它。此时根据上⾯所说的⽐对规则拿版本链中的第⼀个版本的事务ID为300进⾏⽐对⾸先当前这条SELECT语句没有在事务300中进⾏查询然后发现是落在⻩⾊区间⽽且事务300也没有在ReadView的未提交事务数组中所以是可⻅的。即此时在第6时刻点第四个事务所查找到的结果是monkey301。
在第7时刻点事务100执⾏了⼀条UPDATE语句将account表中id为1的name改为了monkey101。
在第8时刻点事务100⼜执⾏了⼀条UPDATE语句将account表中id为1的name改为了monkey102。
在第9时刻点第四个事务执⾏了⼀条SELECT语句想要查询⼀下当前id为1的数据。此时的版本链和ReadView如下 注意因为当前是在可重复读的事务级别下所以此时的ReadView沿⽤了在第6时刻点⽣成的ReadView如果是在读取已提交的事务级别下此时就会重新⽣成⼀份ReadView了。然后根据上⾯所说的⽐对规则拿版本链中的第⼀个版本的事务ID为100进⾏⽐对⾸先当前这条SELECT语句没有在事务100中进⾏查询然后发现是落在⻩⾊区间⽽且事务100是在ReadView的未提交事务数组中所以是不可⻅的。此时通过回滚指针拿取下⼀个版本发现事务ID仍然为100经过分析后还是不可⻅的。此时⼜拿取下⼀个版本事务ID为300进⾏⽐对⾸先当前这条SELECT语句没有在事务300中进⾏查询然后发现是落在⻩⾊区间但是事务300没有在ReadView的未提交事务数组中所以是可⻅的。即此时在第9时刻点第四个事务所查找到的结果仍然是monkey301这也就是可重复读的含义。
在第10时刻点事务100commit提交事务了。同时事务200执⾏了⼀条UPDATE语句将account表中id为1的name改为了monkey201。
在第11时刻点事务200⼜执⾏了⼀条UPDATE语句将account表中id为1的name改为了monkey202。
在第12时刻点第四个事务执⾏了⼀条SELECT语句想要查询⼀下当前id为1的数据。此时的版本链和ReadView如下 跟第9时刻点⼀样在可重复读的事务级别下ReadView沿⽤了在第6时刻点⽣成的ReadView。然后根据上⾯所说的⽐对规则拿版本链中的第⼀个版本的事务ID为200进⾏⽐对⾸先当前这条SELECT语句没有在事务200中进⾏查询然后发现是落在⻩⾊区间⽽且事务200是在ReadView的未提交事务数组中所以是不可⻅的。此时通过回滚指针拿取下⼀个版本发现事务ID仍然为200经过分析后还是不可⻅的。此时⼜拿取下⼀个版本事务ID为100进⾏⽐对⾸先当前这条SELECT语句没有在事务100中进⾏查询然后发现是落在⻩⾊区间内同时在ReadView的未提交数组中所以依然是不可⻅的。此时⼜拿取下⼀个版本发现事务ID仍然为100经过分析后还是不可⻅的。此时再拿取下⼀个版本事务ID为300进⾏⽐对⾸先当前这条SELECT语句没有在事务300中进⾏查询然后发现是落在⻩⾊区间但是事务300没有在ReadView的未提交事务数组中所以是可⻅的。即此时在第12时刻点第四个事务所查找到的结果仍然是monkey301。
同时在第12时刻点第五个事务执⾏了⼀条SELECT语句想要查询⼀下当前id为1的数据。此时的版本链和ReadView如下 注意此时第五个事务因为是该事务内的第⼀条SELECT语句所以会重新⽣成在当前情况下的ReadView即上图中所示的内容。可以看到和第四个事务⽣成的ReadView并不⼀样因为在之前的第10时刻点事务100已经提交事务了。然后根据上⾯所说的⽐对规则拿版本链中的第⼀个版本的事务ID为200进⾏⽐对⾸先当前这条SELECT语句没有在事务200中进⾏查询然后发现是落在⻩⾊区间⽽且事务200是在ReadView的未提交事务数组中所以是不可⻅的。此时通过回滚指针拿取下⼀个版本发现事务ID仍然为200经过分析后还是不可⻅的。此时⼜拿取下⼀个版本事务ID为100进⾏⽐对发现是在绿⾊区间所以是可⻅的。即此时在第12时刻点第五个事务所查找到的结果是monkey102可以看到即使是同⼀条SELECT语句在不同的事务中查询出来的结果也可能是不同的究其原因就是因为ReadView的不同。
在第13时刻点事务200执⾏了commit操作整段分析过程结束。
以上演示的就是MVCC的具体执⾏过程在多个事务下版本链和ReadView是如何配合进⾏查找的。上⾯还遗漏了⼀种情况没有进⾏说明就是如果是DELETE语句的话也会在版本链上将最新的数据插⼊⼀份然后将事务ID赋值为当前进⾏删除操作的事务ID。但是同时会在该条记录的信息头recordheader⾥⾯的deleted_flag标记位置为true以此来表示当前记录已经被删除。所以如果经过版本⽐对 后发现找到的版本上的deleted_flag标记位为true的话那么也不会返回⽽是继续寻找下⼀个。
另外如果当前事务执⾏rollback回滚的话会把版本链中属于该事务的所有版本都删除掉
