网站建设维护人员,芜湖seo,野花高清中文免费观看视频,网站怎么看好与不好ACID原则、事务隔离级别及事务机制原理
一、事务的ACID原则
什么是事务呢#xff1f;事务通常是由一个或一组SQL组成的#xff0c;组成一个事务的SQL一般都是一个业务操作#xff0c;例如聊到的下单#xff1a;「扣库存数量、增加订单详情记录、插入物流信息」#xff0…ACID原则、事务隔离级别及事务机制原理
一、事务的ACID原则
什么是事务呢事务通常是由一个或一组SQL组成的组成一个事务的SQL一般都是一个业务操作例如聊到的下单「扣库存数量、增加订单详情记录、插入物流信息」这一组SQL就可以组成一个事务。 而数据库的事务一般也要求满足ACID原则ACID是关系型数据库实现事务机制时必须要遵守的原则。 ACID主要涵盖四条原则即 • A/Atomicity原子性 • C/Consistency一致性 • I/Isolation独立性/隔离性 • D/Durability持久性
1.1、Atomicity原子性
原子性这个概念而在MySQL中原子性的含义也大致相同指组成一个事务的一组SQL要么全部执行成功要么全部执行失败事务中的一组SQL会被看成一个不可分割的整体当成一个操作看待。 好比事务A由①、②、③条SQL组成那这一个事务中的三条SQL必须全部执行成功只要其中任意一条执行失败例如②执行时出现异常了此时就会导致事务A中的所有操作全部失败。 1.2、Consistency一致性
不管事务发生的前后MySQL中原本的数据变化都是一致的也就是DB中的数据只允许从一个一致性状态变化为另一个一致性状态。简单解释一下就是一个事务中的所有操作要么一起改变数据库中的数据要么都不改变对于其他事务而言数据的变化是一致的。
1.3、Isolation独立性/隔离性
简单理解原子性和一致性后再来看看ACID中的隔离性在有些地方也称之为独立性意思就是指多个事务之间都是独立的相当于每个事务都被装在一个箱子中每个箱子之间都是隔开的相互之间并不影响。
1.4、Durability持久性
相较于之前的原子性、一致性、隔离性来说持久性是ACID原则中最容易理解的一条持久性是指一个事务一旦被提交它会保持永久性所更改的数据都会被写入到磁盘做持久化处理就算MySQL宕机也不会影响数据改变因为宕机后也可以通过日志恢复数据。
二、MySQL的事务机制综述
ACID原则是数据库事务的四个特性也可以理解为实现事务的基础理论。在MySQL默认情况下一条SQL会被视为一个单独的事务同时也无需咱们手动提交因为默认是开启事务自动提交机制的如若你想要将多条SQL组成一个事务执行那需要显式的通过一些事务指令来实现。
2.1、手动管理事务
在MySQL中提供了一系列事务相关的命令如下 start transaction | begin | begin work开启一个事务 commit提交一个事务 rollback回滚一个事务
事务是基于当前数据库连接而言的而不是基于表一个事务可以由操作不同表的多条SQL组成这句话什么意思呢 上面画出了两个数据库连接假设连接A中开启了一个事务那后续过来的所有SQL都会被加入到一个事务中也就是图中连接A后面的SQL②、SQL③、SQL④、SQL⑤这四条都会被加入到一个事务中只要在未曾收到commit/rollback命令之前这个连接来的所有SQL都会加入到同一个事务中因此对于这点要牢记开启事务后一定要做提交或回滚处理。 不过在连接A中开启事务是不会影响连接B的这也是我说的事务是基于当前数据库连接的每个连接之间的事务是具备隔离性的。 这里插个小偏门知识当你在Navicat、SQLyog这类可视化工具中新建一个查询时本质上它就是给你建立了一个数据库连接每一个新查询都是一个新的连接。
-- 查看 自动提交事务 是否开启
SHOW VARIABLES LIKE autocommit;-- 关闭或开启自动提交
SET autocommit 0|1|ON|OFF;
上述的[0/ON]是相同的意思表示开启自动提交[1/OFF]则表示关闭自动提交。
2.2、事务回滚点
在上面简单阐述了事务的基本使用但假设目前有一个事务由很多条SQL组成但是我想让其中一部分执行成功后就算后续SQL执行失败也照样提交这样可以做到吗从前面的理论上来看一个事务要么全部执行成功要么全部执行失败似乎做不到啊但实际上是可以做到的这里需要利用事务的回滚点机制。 在某些SQL执行成功后但后续的操作有可能成功也有可能失败但不管成功亦或失败你都想让前面已经成功的操作生效时此时就可在当前成功的位置设置一个回滚点。当后续操作执行失败时就会回滚到该位置而不是回滚整个事务中的所有操作这个机制则称之为事务回滚点。 在MySQL中提供了两个关于事务回滚点的命令 savepoint point_name添加一个事务回滚点 rollback to point_name回滚到指定的事务回滚点
-- 先查询一次用户表
SELECT * FROM zz_users;
-- 开启事务
start transaction;
-- 修改 ID4 的姓名为黑熊
update zz_users set user_name 黑熊 where user_id 4;
-- 添加一个事务回滚点update_name
savepoint update_name;
-- 删除 ID1 的行数据
delete from zz_users where user_id 1;
-- 回滚到 update_name 这个事务点
rollback to update_name;
-- 再次查询一次数据
SELECT * FROM zz_users;
-- 提交事务
COMMIT;
上述代码中开启了一个事务事务中总共修改和删除两条SQL组成然后在修改语句后面添加了一个事务回滚点update_name在删除语句后回滚到了前面添加的回滚点。 但要注意回滚到事务点后不代表着事务结束了只是事务内发生了一次回滚如果要结束当前这个事务还依旧需要通过commit|rollback;命令处理。 其实借助事务回滚点可以很好的实现失败重试比如对事务中的每个SQL添加一个回滚点当执行一条SQL时失败了就回滚到上一条SQL的事务点接着再次执行失败的SQL反复执行到所有SQL成功为止最后再提交整个事务。
2.3、MySQL事务的隔离机制
不同的数据库连接中一个连接的事务并不会影响其他连接当时也稍微的提过一嘴这是基于事务隔离机制实现的那接下来重点聊一聊MySQL的事务隔离机制。其实在MySQL中事务隔离机制分为了四个级别 ①Read uncommitted/RU读未提交 ②Read committed/RC读已提交 ③Repeatable read/RR可重复读 ④Serializable序列化/串行化
上述四个级别越靠后并发控制度越高也就是在多线程并发操作的情况下出现问题的几率越小但对应的也性能越差MySQL的事务隔离级别默认为第三级别Repeatable read可重复读。
2.3.1、脏读、幻读、不可重复读问题
数据库的脏读问题
首先来看看脏读脏读的意思是指一个事务读到了其他事务还未提交的数据也就是当前事务读到的数据由于还未提交因此有可能会回滚如下 在个案例中事务A先扣减了库存然后事务回滚时又加了回去但连接②已经将扣减后的库存数量读回去操作了这个过程就被称为数据库脏读问题。这个问题很严重会导致整个业务系统出现问题数据最终错乱。 数据库的不可重复读问题
再来看看不可重复读问题不可重复读问题是指在一个事务中多次读取同一数据先后读取到的数据不一致如下 在上述这个案例中同一个事务中读取同一数据结果却并不一致也就说明了该数据存在不可重复读问题。 可重复读在同一事务中不管读取多少次读到的数据都是相同的。 数据库的幻读问题 幻读指同一个事务内多次查询返回的结果集不一样。比如同一个事务A在第一次查询表的数据行数时发现表中有n条行记录但是第二次以同等条件查询时却发现有n1条记录这就好像产生了幻觉。 这个说法实际上并不严谨第一次读和第二次读同一数据结果集并不相同这其实属于一个不可重复读的问题而并非幻读问题。那接下来举例说明一下什么叫做真正的幻读问题先上图 发生幻读问题的原因是在于另外一个事务在第一个事务要处理的目标数据范围之内新增了数据然后先于第一个事务提交造成的问题。
数据库脏写问题
其实除开三个读的问题外还有有一个叫做脏写的问题也就是多个事务一起操作同一条数据例如两个事务同时向表中添加一条ID88的数据此时就会造成数据覆盖或者主键冲突的问题这个问题也被称之为更新丢失问题。
2.3.2、事务的四大隔离级别
其实四个事务隔离级别解决的实际问题就是这三个因此一起来看看各级别分别解决了什么问题 ①读未提交处于该隔离级别的数据库脏读、不可重复读、幻读问题都有可能发生。 ②读已提交处于该隔离级别的数据库解决了脏读问题不可重复读、幻读问题依旧存在。 ③可重复读处于该隔离级别的数据库解决了脏读、不可重复读问题幻读问题依旧存在。 ④序列化/串行化处于该隔离级别的数据库解决了脏读、不可重复读、幻读问题都不存在。
前面提到过MySQL默认是处于第三级别的可以通过如下命令查看目前数据库的隔离级别
-- 查询方式①
SELECT tx_isolation;
-- 查询方式②
show variables like %tx_isolation%;
--------------------------------
| Variable_name | Value |
--------------------------------
| tx_isolation | REPEATABLE-READ |
--------------------------------
其实数据库不同的事务隔离级别是基于不同类型、不同粒度的锁实现的。事务是基于数据库连接的数据库连接本身会有一条工作线程来维护也就是说事务的执行本质上就是工作线程在执行因此所谓的并发事务也就是指多条线程并发执行。
读未提交级别
这种隔离级别是基于「写互斥锁」实现的当一个事务开始写某一个数据时另外一个事务也来操作同一个数据此时为了防止出现问题则需要先获取锁资源只有获取到锁的事务才允许对数据进行写操作同时获取到锁的事务具备排他性/互斥性也就是其他线程无法再操作这个数据。 但这个级别中写同一数据时会互斥但读操作却并不是互斥的也就是当一个事务在写某个数据时就算没有提交事务其他事务来读取该数据时也可以读到未提交的数据因此就会导致脏读、不可重复读、幻读一系列问题出现。 但是由于在这个隔离级别中加了「写互斥锁」因此不会存在多个事务同时操作同一数据的情况因此这个级别中解决了前面说到的脏写问题。
读已提交级别
在这个隔离级别中对于写操作同样会使用「写互斥锁」也就是两个事务操作同一数据时会出现排他性而对于读操作则使用了一种名为MVCC多版本并发控制的技术处理也就是有事务中的SQL需要读取当前事务正在操作的数据时MVCC机制不会让另一个事务读取正在修改的数据而是读取上一次提交的数据也就是读原本的老数据。 也就是在这个隔离级别中基于同一条数据而言对于写操作会具备排他性对于读操作则只能读已提交事务的数据不会读取正在操作但还未提交的事务数据。 事务A的主要工作是负责更新ID1的这条数据事务B中则是读取ID1的这条数据。 此时当A正在更新数据但还未提交时事务B开始读取数据此时MVCC机制则会基于表数据的快照创建一个ReadView然后读取原本表中上一次提交的老数据。然后等事务A提交之后事务B再次读取数据此时MVCC机制又会创建一个新的ReadView然后读取到最新的已提交的数据此时事务B中两次读到的数据并不一致因此出现了不可重复读问题。
可重复读级别
在这个隔离级别中主要就是解决上一个级别中遗留的不可重复读问题但MySQL依旧是利用MVCC机制来解决这个问题的只不过在这个级别的MVCC机制会稍微有些不同。在读已提交级别中一个事务中每次查询数据时都会创建一个新的ReadView然后读取最近已提交的事务数据因此就会造成不可重复读的问题。 而在可重复读级别中则不会每次查询时都创建新的ReadView而是在一个事务中只有第一次执行查询会创建一个ReadView在这个事务的生命周期内所有的查询都会从这一个ReadView中读取数据从而确保了一个事务中多次读取相同数据是一致的也就是解决了不可重复读问题。 虽然在这个隔离级别中解决了不可重复读问题但依旧存在幻读问题也就是事务A在对表中多行数据进行修改。
序列化/串行化级别
这个隔离级别是最高的级别处于该隔离级别的MySQL绝不会产生任何问题因为从它的名字上就可以得知序列化意思是将所有的事务按序排队后串行化处理也就是操作同一张表的事务只能一个一个执行事务在执行前需要先获取表级别的锁资源拿到锁资源的事务才能执行其余事务则陷入阻塞等待当前事务释放锁。 但这种隔离级别会导致数据库的性能直线下降毕竟相当于一张表上只能允许单条线程执行了虽然安全等级最高可以解决脏写、脏读、不可重复读、幻读等一系列问题但也是代价最高的一般线上很少使用。 这种隔离级别解决问题的思想很简单之前我们分析过产生一系列问题的根本原因在于多事务/多线程并发执行导致的那在这个隔离级别中直接将多线程化为了单线程自然也就从根源上避免了问题产生。
其实在RR级别中也可以解决幻读问题就是使用临键锁间隙锁行锁这种方式来加锁。
2.3.3、事务隔离机制的命令
简单认识MySQL事务隔离机制后接着来看看一些关于事务隔离机制的命令
-- 方式①查询当前数据库的隔离级别
SELECT tx_isolation;
-- 方式②查询当前数据库的隔离级别
show variables like %tx_isolation%;
-- 设置隔离级别为RU级别当前连接生效
set transaction isolation level read uncommitted;
-- 设置隔离级别为RC级别全局生效
set global transaction isolation level read committed;
-- 设置隔离级别为RR级别当前连接生效
-- 这里和上述的那条命令作用相同是第二种设置的方式
set tx_isolation repeatable-read;
-- 设置隔离级别为最高的serializable级别全局生效
set global.tx_isolation serializable;
唯一要注意的在于如果想要让设置的隔离级别在全局生效一定要记得加上global关键字否则生效范围是当前会话也就是针对于当前数据库连接有效在其他连接中依旧是原本的隔离级别。
三、MySQL的事务实现原理
**MySQL的事务机制是基于日志实现的**。为什么是基于日志实现的呢
3.1、正常SQL的事务机制
**MySQL默认开启事务的自动提交并且将一条SQL视为一个事务**。任意一条写SQL的执行都会记录三个日志undo-log、redo-log、bin-log。 undo-log主要记录SQL的撤销日志比如目前是insert语句就记录一条delete日志。 redo-log记录当前SQL归属事务的状态以及记录修改内容和修改页的位置。 bin-log记录每条SQL操作日志只要是用于数据的主从复制与数据恢复/备份。
在写SQL执行记录的三个日志中bin-log暂且不需要关心这个跟事务机制没关系重点是undo-log、redo-log这两个日志其中最重要的是redo-log这个日志。 redo-log是一种WAL(Write-ahead logging)预写式日志在数据发生更改之前会先记录日志也就是在SQL执行前会先记录一条prepare状态的日志然后再执行数据的写操作。 但要注意MySQL是基于磁盘的但磁盘的写入速度相较内存而言会较慢因此MySQL-InnoDB引擎中不会直接将数据写入到磁盘文件中而是会先写到BufferPool缓冲区中当SQL被成功写入到缓冲区后紧接着会将redo-log日志中相应的记录改为commit状态然后再由MySQL刷盘机制去做具体的落盘操作。 因为默认情况下一条SQL会被当成一个事务数据写入到缓冲区后就代表执行成功因此会自动修改日志记录为commit状态后续则会由MySQL的后台线程执行刷盘动作。 举个伪逻辑的例子例如下述这条插入SQL的执行过程大致如下
-- 先记录一条状态为 prepare 的日志
-- 然后执行SQL在缓冲区中更改对应的数据
INSERT INTO zz_users VALUES(5,黑竹,男,9999,2022-09-24 23:48:29);
-- 写入缓冲区成功后将日志记录改为 commit状态
-- 返回 [Affected rows: 1]MySQL后台线程执行刷盘动作
3.2、多条SQL的事务机制
-- 开启事务
start transaction;
-- 修改 ID4 的姓名为黑熊原本user_name 1111
update zz_users set user_name 黑熊 where user_id 4;
-- 删除 ID1 的行数据
delete from zz_users where user_id 1;
-- 提交事务
COMMIT;
①当MySQL执行时碰到start transaction;的命令时会将后续所有写操作全部先关闭自动提交机制也就是后续的所有写操作不管有没有成功都不会将日志记录修改为commit状态。
②先在redo-log中为第一条SQL语句记录一条prepare状态的日志然后再生成对应的撤销日志并记录到undo-log中然后执行SQL将要写入的数据先更新到缓冲区。
③再对第二条SQL语句做相同处理如果有更多条SQL则逐条依次做相同处理..... 这里简单的说一下撤销日志长啥样大致如下
-- 第一条修改SQL的撤销日志将修改的姓名字段从 黑熊 改回 1111
update zz_users set user_name 1111 where user_id 4;
-- 第二条删除SQL的撤销日志将删除的行数据再次插入
INSERT INTO zz_users VALUES(1,熊猫,女,6666,2022-08-14 15:22:01);
④直到碰到了rollback、commit命令时再对前面的所有写SQL做相应处理 如果是commit提交事务的命令则先将当前事务中所有的SQL的redo-log日志改为commit状态然后由MySQL后台线程做刷盘将缓冲区中的数据落入磁盘存储。 如果是rollback回滚事务的命令则在undo-log日志中找到对应的撤销SQL执行将缓冲区内更新过的数据全部还原由于缓冲区的数据被还原了因此后台线程在刷盘时依旧不会改变磁盘文件中存储的数据。 3.3、事务的恢复机制
当SQL执行时数据还没被刷写到磁盘中结果数据库宕机了那数据是不是就丢了啊毕竟本地磁盘中的数据在MySQL重启后依旧存在但缓冲区中还未被刷到磁盘的数据呢因为缓冲区位于内存中所以里面的数据重启是不会存在的撒 对于这个问题呢实际上并不需要担心因为前面聊到过redo-log是一种预写式日志会先记录日志再去更新缓冲区中的数据所以就算缓冲区的数据未被刷写到磁盘在MySQL重启时依旧可以通过redo-log日志重新恢复未落盘的数据从而确保数据的持久化特性。 那如果在记录redo-log日志时MySQL宕机咋整
首先看看前面的那种情况数据被更新到缓冲区但没刷盘然后MySQL宕机了MySQL会通过日志恢复数据。这里要注意的是数据被更新到缓冲区代表着SQL执行成功了此时客户端会收到MySQL返回的写入成功提示只是没有落盘而言所以MySQL重启后只需要再次落盘即可。 但如果在记录日志的时候MySQL宕机了这代表着SQL都没执行成功SQL没执行成功的话MySQL也不会向客户端返回任何信息因为MySQL一直没返回执行结果因此会导致客户端连接超时而一般客户端都会有超时补偿机制的比如会超时后重试如果MySQL做了热备/灾备这个重试的时间足够MySQL重启完成了因此用户的操作依旧不会丢失对于超时补偿机制在各大数据库连接池中是有实现的。 MySQL也没做热备/灾备这类的方案呐 MySQL挂了一直不重启不仅仅当前的SQL会丢失后续平台上所有的用户操作都会无响应这属于系统崩溃级别的灾难了因此只能靠完善系统架构来解决。 四、MySQL事务篇总结
再次结合undo-log、redo-log日志来看待ACID的四大特性原子性、一致性、隔离性、持久性。 原子性要求事务中所有操作要么全部成功要么全部失败这点是基于undo-log来实现的因为在该日志中会生成相应的反SQL执行失败时会利用该日志来回滚所有写入操作。 持久性要求的是所有SQL写入的数据都必须能落入磁盘存储确保数据不会丢失这点则是基于redo-log实现的。 隔离性的要求是一个事务不会受到另一个事务的影响对于这点则是通过锁机制和MVCC机制实现的只不过MySQL屏蔽了加锁和MVCC的细节。 一致性要求数据库的整体数据变化只能从一个一致性状态变为另一个一致性状态其实前面的原子性、持久性、隔离性都是为了确保这点而存在的。
什么是排他锁、共享锁、意向锁
共享锁
共享锁又被称为读锁是由读取操作所创建的一种锁。在此期间其他用户可以同时读取数据但在数据上未释放所有共享锁之前任何事务均无法对其进行修改即获取数据的排他锁。
一旦事务T对数据A加上共享锁其他事务只能对A再加共享锁而无法加排他锁。获得共享锁的事务仅可读取数据不可修改数据。
SELECT ... LOCK IN SHARE MODE;
在查询语句后增加LOCK IN SHARE MODEMySQL会对查询结果中的每一行都加上共享锁。当没有其他线程对查询结果集中的任何一行使用排他锁时可以成功申请共享锁否则会被阻塞。其他线程也可以读取已被共享锁保护的表且这些线程读取的是同一版本的数据。
排他锁
排他锁又称为写锁。如果事务T对数据A加上排他锁则其他事务无法对A加任何类型的锁。获得排他锁的事务既能读取数据又能修改数据。
SELECT ... FOR UPDATE;
在查询语句后增加FOR UPDATEMySQL会对查询结果中的每一行记录都加上排他锁。只有在没有其他线程对查询结果集中的任何一行使用排他锁时才能成功申请排他锁否则会被阻塞。
意向锁
在MySQL的InnoDB引擎中支持多种锁级别其中包括行级锁和表级锁。当多个事务需要访问同一共享资源时如果每个事务都直接请求获取锁可能会发生相互阻塞的情况甚至可能导致死锁的产生。
假设事务A对表Table1中的某一行加上了行级锁这使得该行记录只能被读取而不能被修改。同时事务B试图对Table1增加表级锁。如果事务B成功获取了表级锁那么它就可以修改表中的任意一行记录这就导致了冲突。
为了解决这个问题需要让事务B在尝试对Table1增加表级锁之前先判断是否有其他事务已经对该表的某行加了行级锁。但是事务B显然不能遍历整个表的数据逐条进行判断是否有加锁。
因此MySQL引入了意向锁机制。意向锁是数据库管理系统中用于实现锁协议的一种机制旨在处理不同锁粒度如行锁和表锁之间的并发性问题。这种机制帮助解决了不同锁粒度之间的并发问题而对于相同锁粒度之间的并发问题可以通过行级互斥锁来解决。
注意 意向锁并非直接用于锁定资源而是用于通知其他事务以避免它们在资源上设置不兼容的锁。 意向锁并非由用户直接请求而是由MySQL管理的。
当一个事务请求获取行级锁或表级锁时MySQL会自动获取相应表的意向锁。这样其他事务在请求获取表锁时就可以首先基于这个意向锁来发现是否已经有其他事务加过锁并根据该锁的类型意向共享锁/意向排他锁来判断自己是否可以获取锁。通过这种方式可以在不阻塞其他事务的情况下为当前事务锁定资源。意向锁有两种类型意向共享锁和意向排他锁。 意向共享锁表示事务打算在资源上设置共享锁读锁。通常用于表明事务计划读取资源并希望在读取时不会有其他事务设置排他锁。 意向排他锁表示事务打算在资源上设置排他锁写锁。这表示事务计划修改资源并不希望有其他事务同时设置共享或排他锁。
意向锁是一种表级锁在触发意向锁的事务提交或回滚后会被释放。
MySQL之MVCC机制
对于并发事务通常可以通过其提供的各类锁去确保各场景下的线程安全问题从而能够防止脏写、脏读、不可重复读及幻读这类问题出现。 虽然MySQL提供的锁机制确实能解决并发事务带来的一系列问题但由于加锁后会让一部分事务串行化而MySQL本身就是基于磁盘实现的性能无法跟内存型数据库娉美因此并发事务串行化会使其效率更低。 相较于加锁串行化执行MVCC机制的出现则以另一种形式解决了并发事务造成的问题。
一、并发事务的四种场景 并发事务中又会分为四种情况分别是读-读、写-写、读-写、写-读这四种情况分别对应并发事务执行时的四种场景。
1.1、读-读场景
读-读场景即是指多个事务/线程在一起读取一个相同的数据比如事务T1正在读取ID88的行记录事务T2也在读取这条记录两个事务之间是并发执行的。 广为人知的一点MySQL执行查询语句绝对不会对引起数据的任何变化因此对于这种情况而言不需要做任何操作因为不改变数据就不会引起任何并发问题。 1.2、写-写场景
写-写场景也比较简单也就是指多个事务之间一起对同一数据进行写操作比如事务T1对ID88的行记录做修改操作事务T2则对这条数据做删除操作事务T1提交事务后想查询看一下结果连这条数据都不见了这也是所谓的脏写问题也被称为更新覆盖问题对于这个问题在所有数据库、所有隔离级别中都是零容忍的存在最低的隔离级别也要解决这个问题。
1.3、读-写、写-读场景
读-写、写-读实际上从宏观角度来看可以理解成同一种类型的操作但从微观角度而言则是两种不同的情况读-写是指一个事务先开始读然后另一个事务则过来执行写操作写-读则相反主要是读、写发生的前后顺序的区别。 并发事务中同时存在读、写两类操作时这是最容易出问题的场景脏读、不可重复读、幻读都出自于这种场景中当有一个事务在做写操作时读的事务中就有可能出现这一系列问题因此数据库才会引入各种机制解决。 1.4、各场景下解决问题的方案
对于写-写、读-写、写-读这三类场景都是利用加锁的方案确保线程安全但上面说到过加锁会导致部分事务串行化因此效率会下降而MVCC机制的诞生则解决了这个问题。 加锁的目的是什么防止脏写、脏读、不可重复读及幻读这类问题出现。 对于脏写问题这是写-写场景下会出现的写-写场景必须要加锁才能保障安全因此先将该场景排除在外。再想想对于读-写并存的场景中脏读、不可重复读及幻读问题都出自该场景中但实际项目中出现这些问题的几率本身就比较小为了防止一些小概念事件就将所有操纵同一数据的并发读写事务串行化这似乎有些不讲道理。
因此MySQL就基于读-写并存的场景推出了MVCC机制在线程安全问题和加锁串行化之间做了一定取舍让两者之间达到了很好的平衡即防止了脏读、不可重复读及幻读问题的出现又无需对并发读-写事务加锁处理。
二、MySQL-MVCC机制综述
MVCC机制的全称为Multi-Version Concurrency Control即多版本并发控制技术主要是为了提升数据库并发性能而设计的其中采用更好的方式处理了读-写并发冲突做到即使有读写冲突时也可以不加锁解决从而确保了任何时刻的读操作都是非阻塞的。 但与其说是MySQL-MVCC机制还不如说是InnoDB-MVCC机制因为在MySQL众多的开源存储引擎中几乎只有InnoDB实现了MVCC机制类似于MyISAM、Memory等引擎中都未曾实现。 2.1、MVCC技术在日常生活中的体现 假设发布了一篇关于《MySQL事务机制》的文章发布后挺受欢迎的因此有不少小伙伴在看其中有一位小伙伴比较细心文中存在两三个错别字被这位小伙伴指出来了因此我去修正错别字后重新发布。 问题来了对于文章首次发布也好重新发布也罢绝对要等审核通过后才会正式发布的那我修正文章后重新发布文章又会进入「审核中」这个状态此时对于其他正在看、准备看的小伙伴来说文章是不是就不见了毕竟文章还在审核因此对这个业务需求又该如何实现呢多版本。 对于首次发布后通过审核的文章在后续重新发布审核时用户可以看到更新前的文章也就是看到老版本的文章当更新后的文章审核通过后再使用新版本的文章代替老版本的文章即可。 这样就能做到新老版本的兼容也能够确保文章修正时其他正在阅读的小伙伴不会受影响而MySQL-MVCC机制的思想也大致相同。
2.2、MySQL-MVCC多版本并发控制
MySQL中的多版本并发控制也和上面给出的例子类似毕竟回想一下脏读、不可重复读、幻读问题都是由于多个事务并发读写导致的但这些问题都是基于最新版本的数据并发操作才会出现那如果读、写的事务操作的不是同一个版本呢比如写操作走新版本读操作走老版本这样是不是无论执行写操作的事务操作了什么都不会影响读的事务答案是Yes。 不过要稍微记住MySQL中仅在RC读已提交级别、RR可重复读级别才会使用MVCC机制。 因为如果是RU读未提交级别既然都允许存在脏读问题、允许一个事务读取另一个事务未提交的数据那自然可以直接读最新版本的数据因此无需MVCC介入。
同时如若是Serializable串行化级别因为会将所有的并发事务串行化处理也就是不论事务是读操作亦或是写操作都会被排好队一个个执行这都不存在所谓的多线程并发问题了自然也无需MVCC介入。 因此要牢记MVCC机制在MySQL中仅有InnoDB引擎支持而在该引擎中MVCC机制只对RC、RR两个隔离级别下的事务生效。当然RC、RR两个不同的隔离级别中MVCC的实现也存在些许差异对于这点后续详细讲解。 三、MySQL-MVCC机制实现原理剖析
MVCC机制主要通过隐藏字段、Undo-log日志、ReadView这三个东西实现的因而也被称为“MVCC三剑客”。
3.1、InnoDB表的隐藏字段
通常而言当你基于InnoDB引擎建立一张表后MySQL除开会构建你显式声明的字段外通常还会构建一些InnoDB引擎的隐藏字段在InnoDB引擎中主要有DB_ROW_ID、DB_Deleted_Bit、DB_TRX_ID、DB_ROLL_PTR这四个隐藏字段。
3.1.1、隐藏主键 - ROW_ID6Bytes
对于InnoDB引擎的表而言由于其表数据是按照聚簇索引的格式存储因此通常都会选择主键作为聚簇索引列然后基于主键字段构建索引树但如若表中未定义主键则会选择一个具备唯一非空属性的字段作为聚簇索引的字段来构建树。 当两者都不存在时InnoDB就会隐式定义一个顺序递增的列ROW_ID来作为聚簇索引列。 因此要牢记一点如果你选择的引擎是InnoDB就算你的表中未定义主键、索引其实默认也会存在一个聚簇索引只不过这个索引在上层无法使用仅提供给InnoDB构建树结构存储表数据。
3.1.2、删除标识 - Deleted_Bit1Bytes
对于一条delete语句而言当执行后并不会立马删除表的数据而是将这条数据的Deleted_Bit删除标识改为1/true后续的查询SQL检索数据时如果检索到了这条数据但看到隐藏字段Deleted_Bit1时就知道该数据已经被其他事务delete了因此不会将这条数据纳入结果集。 设计Deleted_Bit这个隐藏字段的好处是什么呢主要是能够有利于聚簇索引比如当一个事务中删除一条数据后后续又执行了回滚操作假设此时是真正的删除了表数据会发生什么情况呢 ①删除表数据时有可能会破坏索引树原本的结构导致出现叶子节点合并的情况。 ②事务回滚时又需重新插入这条数据再次插入时又会破坏前面的结构导致叶子节点分裂。 综上所述如果执行delete语句就删除真实的表数据由于事务回滚的问题就很有可能导致聚簇索引树发生两次结构调整这其中的开销可想而知而且先删除再回滚最终树又变成了原状那这两次树的结构调整还是无意义的。 所以当执行delete语句时只会改变将隐藏字段中的删除标识改为1/true如果后续事务出现回滚动作直接将其标识再改回0/false即可这样就避免了索引树的结构调整。 但如若事务删除数据之后提交了事务呢总不能让这条数据一直留在磁盘吧毕竟如果所有的delete操作都这么干就会导致磁盘爆满显然这样是不妥的因此删除标识为1/true的数据最终依旧会从磁盘中移除啥时候移呢 MySQL中存在purger线程的概念为了防止“已删除”的数据占用过多的磁盘空间purger线程会自动清理Deleted_Bit1/true的行数据。 为了确保清理数据时不会影响MVCC的正常工作purger线程自身也会维护一个ReadView如果某条数据的Deleted_Bittrue并且TRX_ID对purge线程的ReadView可见那么这条数据一定是可以被安全清除的即不会影响MVCC工作。 3.1.3、最近更新的事务ID - TRX_ID6Bytes
TRX_ID全称为transaction_id翻译过来也就是事务ID的意思MySQL对于每一个创建的事务都会为其分配一个事务ID事务ID同样遵循顺序递增的特性即后来的事务ID绝对会比之前的ID要大比如 此时事务T1准备修改表字段的值MySQL会为其分配一个事务ID1当事务T2准备向表中插入一条数据时又会为这个事务分配一个ID2...... 但有一个细节点需要记住MySQL对于所有包含写入SQL的事务会为其分配一个顺序递增的事务ID但如果是一条select查询语句则分配的事务ID0。 不过对于手动开启的事务MySQL都会为其分配事务ID就算这个手动开启的事务中仅有select操作。 表中的隐藏字段TRX_ID记录的就是最近一次改动当前这条数据的事务ID这个字段是实现MVCC机制的核心之一。
3.1.4、回滚指针 - ROLL_PTR7Bytes
ROLL_PTR全称为rollback_pointer也就是回滚指针的意思这个也是表中每条数据都会存在的一个隐藏字段当一个事务对一条数据做了改动后都会将旧版本的数据放到Undo-log日志中而rollback_pointer就是一个地址指针指向Undo-log日志中旧版本的数据当需要回滚事务时就可以通过这个隐藏列来找到改动之前的旧版本数据而MVCC机制也利用这点实现了行数据的多版本。
3.2、InnoDB引擎的Undo-log日志
MySQL事务机制是基于Undo-log实现的同时在刚刚在聊回滚指针时聊到了Undo-log日志中会存储旧版本的数据但要注意Undo-log中并不仅仅只存储一条旧版本数据其实在该日志中会有一个版本链。
SELECT * FROM zz_users WHERE user_id 1;
-------------------------------------------------------------
| user_id | user_name | user_sex | password | register_time |
-------------------------------------------------------------
| 1 | 熊猫 | 女 | 6666 | 2022-08-14 15:22:01 |
-------------------------------------------------------------UPDATE zz_users SET user_name 竹子 WHERE user_id 1;
UPDATE zz_users SET user_sex 男 WHERE user_id 1;
比如上述这段SQL隶属于trx_id1的T1事务其中对同一条数据改动了两次那Undo-log日志中只会存储一条旧版本数据吗NO答案是两条旧版本的数据如下图 Undo版本链
从上图中可明显看出不同的旧版本数据会以roll_ptr回滚指针作为链接点然后将所有的旧版本数据组成一个单向链表。但要注意一点最新的旧版本数据都会插入到链表头中而不是追加到链表尾部。 细说一下执行上述update语句的详细过程 ①对ID1这条要修改的行数据加上排他锁。 ②将原本的旧数据拷贝到Undo-log的rollback Segment区域。 ③对表数据上的记录进行修改修改完成后将隐藏字段中的trx_id改为当前事务ID。 ④将隐藏字段中的roll_ptr指向Undo-log中对应的旧数据并在提交事务后释放锁。 为什么Undo-log日志要设计出版本链呢两个好处一方面可以实现事务点回滚另一方面则可以实现MVCC机制。 与之前的删除标识类似一条数据被delete后并提交了最终会从磁盘移除而Undo-log中记录的旧版本数据同样会占用空间因此在事务提交后也会移除移除的工作同样由purger线程负责purger线程内部也会维护一个ReadView它会以此作为判断依据来决定何时移除Undo记录。 3.3、MVCC核心 - ReadView
MVCC在前面聊到过它翻译过来就是多版本并发控制的意思对于这个名词中的多版本已经通过Undo-log日志实现了但再思考一个问题如果T2事务要查询一条行数据此时这条行数据正在被T1事务写那也就代表着这条数据可能存在多个旧版本数据T2事务在查询时应该读这条数据的哪个版本呢此时就需要用到ReadView用它来做多版本的并发控制根据查询的时机来选择一个当前事务可见的旧版本数据读取。 那究竟什么是ReadView呢就是一个事务在尝试读取一条数据时MVCC基于当前MySQL的运行状态生成的快照也被称之为读视图即ReadView在这个快照中记录着当前所有活跃事务的ID活跃事务是指还在执行的事务即未结束提交/回滚的事务。 当一个事务启动后首次执行select操作时MVCC就会生成一个数据库当前的ReadView通常而言一个事务与一个ReadView属于一对一的关系不同隔离级别下也会存在细微差异ReadView一般包含四个核心内容 creator_trx_id代表创建当前这个ReadView的事务ID。 trx_ids表示在生成当前ReadView时系统内活跃的事务ID列表。 up_limit_id活跃的事务列表中最小的事务ID。 low_limit_id表示在生成当前ReadView时系统中要给下一个事务分配的ID值。
上面四个值很简单值得一提的是low_limit_id它并不是目前系统中活跃事务的最大ID因为之前讲到过MySQL的事务ID是按序递增的因此当启动一个新的事务时都会为其分配事务ID而这个low_limit_id则是整个MySQL中要为下一个事务分配的ID值。
下面上个ReadView的示意图来好好理解一下它 假设目前数据库中共有T1~T5这五个事务T1、T2、T4还在执行T3已经回滚T5已经提交此时当有一条查询语句执行时就会利用MVCC机制生成一个ReadView由于前面讲过单纯由一条select语句组成的事务并不会分配事务ID因此默认为0所以目前这个快照的信息如下
{creator_trx_id : 0,trx_ids : [1,2,4],up_limit_id : 1,low_limit_id : 6
}
3.4、MVCC机制实现原理 ①当一个事务尝试改动某条数据时会将原本表中的旧数据放入Undo-log日志中。 ②当一个事务尝试查询某条数据时MVCC会生成一个ReadView快照。
其中Undo-log主要实现数据的多版本ReadView则主要实现多版本的并发控制还是以之前的例子来举例说明
-- 事务T1trx_id1
UPDATE zz_users SET user_name 竹子 WHERE user_id 1;
UPDATE zz_users SET user_sex 男 WHERE user_id 1;
-- 事务T2trx_id2
SELECT * FROM zz_users WHERE user_id 1;
目前存在T1、T2两个并发事务T1目前在修改ID1的这条数据而T2则准备查询这条数据那么T2在执行时具体过程是怎么回事呢 ①当事务中出现select语句时会先根据MySQL的当前情况生成一个ReadView。 ②判断行数据中的隐藏列trx_id与ReadView.creator_trx_id是否相同 相同代表创建ReadView和修改行数据的事务是同一个自然可以读取最新版数据。 不相同代表目前要查询的数据是被其他事务修改过的继续往下执行。 ③判断隐藏列trx_id是否小于ReadView.up_limit_id最小活跃事务ID 小于代表改动行数据的事务在创建快照前就已结束可以读取最新版本的数据。 不小于则代表改动行数据的事务还在执行因此需要继续往下判断。 ④判断隐藏列trx_id是否小于ReadView.low_limit_id这个值 大于或等于代表改动行数据的事务是生成快照后才开启的因此不能访问最新版数据。 小于表示改动行数据的事务ID在up_limit_id、low_limit_id之间需要进一步判断。 ⑤如果隐藏列trx_id小于low_limit_id继续判断trx_id是否在trx_ids中 在表示改动行数据的事务目前依旧在执行不能访问最新版数据。 不在表示改动行数据的事务已经结束可以访问最新版的数据。
说简单一点就是首先会去获取表中行数据的隐藏列然后经过上述一系列判断后可以得知目前查询数据的事务到底能不能访问最新版的数据。如果能就直接拿到表中的数据并返回反之不能则去Undo-log日志中获取旧版本的数据返回。 注意假设Undo-log日志中存在版本链怎么办该获取哪个版本的旧数据呢 如果Undo-log日志中的旧数据存在一个版本链时此时会首先根据隐藏列roll_ptr找到链表头然后依次遍历整个列表从而检索到最合适的一条数据并返回。但在这个遍历过程中是如何判断一个旧版本的数据是否合适的呢条件如下 旧版本的数据其隐藏列trx_id不能在ReadView.trx_ids活跃事务列表中。
因为如果旧版本的数据其trx_id依旧在ReadView.trx_ids中就代表着产生这条旧数据的事务还未提交自然不能读取这个版本的数据以前面给出的例子来说明 这是由事务T1生成的版本链此时T2生成的ReadView如下
{creator_trx_id : 0,trx_ids : [1],up_limit_id : 1,low_limit_id : 2
}
结合这个ReadView信息经过前面那一系列判断后最终会得到不能读取最新版数据因此需要去Undo-log的版本链中读数据首先根据roll_ptr找到第一条旧数据 第一条旧数据 此时发现其trx_id1位于ReadView.trx_ids中因此不能读取这条旧数据接着再根据这条旧数据的roll_ptr找到第二条旧版本数据 第二条旧数据 这时再看其trx_idnull并不位于ReadView.trx_ids中null表示这条数据在上次MySQL运行时就已插入了因此这条旧版本的数据可以被T2事务读取最终T2就会查询到这条数据并返回。 范围查询时突然出现新增数据怎么办呢 SELECT * FROM zz_users;
-------------------------------------------------------------
| user_id | user_name | user_sex | password | register_time |
-------------------------------------------------------------
| 1 | 熊猫 | 女 | 6666 | 2022-08-14 15:22:01 |
| 2 | 竹子 | 男 | 1234 | 2022-09-14 16:17:44 |
| 3 | 子竹 | 男 | 4321 | 2022-09-16 07:42:21 |
| 4 | 猫熊 | 女 | 8888 | 2022-09-27 17:22:59 |
| 9 | 黑竹 | 男 | 9999 | 2022-09-28 22:31:44 |
--------------------------------------------------------------- T1事务查询ID 3 的所有用户信息
select * from zz_users where user_id 3;-- T2事务新增一条 ID 6 的用户记录
INSERT INTO zz_users VALUES(6,棕熊,男,7777,2022-10-02 16:21:33);
此时当T1事务查询数据时突然蹦出来一条ID6的数据经过判断之后会发现新增这条数据的事务还在执行所以要去查询旧版本数据但此时由于是新增操作因此roll_ptrnull即表示没有旧版本数据此时会不会读取最新版的数据呢答案是NO如果查询数据的事务不能读取最新版数据同时又无法从版本链中找到旧数据那就意味着这条数据对T1事务完全不可见因此T1的查询结果中不会包含ID6的这条新增记录。 附加说明如果这个一个修改数据的事务正好快照生成结束后才开启的并且多次修改了目前select操作要读取的目标数据行因此在Undo版本链中会产生一系列旧数据但根据前面的一系列判断最终select事务会去版本链中找数据此时后面这个修改事务的ID恰巧不在快照到trx_ids列表中怎么办呢 面对于这种情况当MVCC发现旧版本的数据其隐藏列的trx_id大于目前快照的最大事务ID时MVCC会自动跳过该版本的数据Why因为MySQL在分配事务ID时都是以递增的顺序分配所以当旧版本上的trx_id大于快照的最大事务ID时说明这条旧版本数据是在快照生成之后产生的所以会跳过对应的旧版本数据不读取。 3.5、RC、RR不同级别下的MVCC机制 ReadView是一个事务中只生成一次还是每次select时都会生成呢 这个问题的答案跟事务的隔离机制有关不同级别的隔离机制也并不同如果此时MySQL的事务隔离机制处于RC读已提交级别那此时来看一个例子
-- 开启一个事务T1主要是修改两次ID1的行数据
begin;
UPDATE zz_users SET user_name 竹子 WHERE user_id 1;
UPDATE zz_users SET user_sex 男 WHERE user_id 1;-- 再开启一个事务T2主要是查询ID1的行数据
SELECT * FROM zz_users WHERE user_id 1;-- 此时先提交事务T1
commit;-- 再次在事务T2中查一次ID1的行数据
SELECT * FROM zz_users WHERE user_id 1;
再来看看上述这个案例如果是处于RC级别的情况下T2事务中的查询结果如下
SELECT * FROM zz_users WHERE user_id 1;
-------------------------------------------------------------
| user_id | user_name | user_sex | password | register_time |
-------------------------------------------------------------
| 1 | 熊猫 | 女 | 6666 | 2022-08-14 15:22:01 |
-------------------------------------------------------------SELECT * FROM zz_users WHERE user_id 1;
-------------------------------------------------------------
| user_id | user_name | user_sex | password | register_time |
-------------------------------------------------------------
| 1 | 竹子 | 男 | 6666 | 2022-08-14 15:22:01 |
-------------------------------------------------------------
为什么两次查询结果不一样呢因为RC级别下MVCC机制是会在每次select语句执行前都会生成一个ReadView由于T2事务中第二次查询数据时T1已经提交了所以第二次查询就能读到修改后的数据这是啥问题不可重复读问题。 接着再来看看RR可重复级别下的MVCC机制SQL代码和上述一模一样但查询结果如下 SELECT * FROM zz_users WHERE user_id 1;
-------------------------------------------------------------
| user_id | user_name | user_sex | password | register_time |
-------------------------------------------------------------
| 1 | 熊猫 | 女 | 6666 | 2022-08-14 15:22:01 |
-------------------------------------------------------------SELECT * FROM zz_users WHERE user_id 1;
-------------------------------------------------------------
| user_id | user_name | user_sex | password | register_time |
-------------------------------------------------------------
| 1 | 熊猫 | 女 | 6666 | 2022-08-14 15:22:01 |
-------------------------------------------------------------
这又是为啥为啥明明在T2事务第二次查询前T1已经提交了T2依旧查询出的结果和第一次相同呢这是因为在RR级别中一个事务只会在首次执行select语句时生成快照后续所有的select操作都会基于这个ReadView来判断这样也就解决了RC级别中存在的不可重复问题。 实际上InnoDB引擎中是可以在RC级别解决脏读、不可重复读、幻读这一系列问题的但是为了将事务隔离级别设计的符合DBMS规范因此在实现时刻意保留了这些问题然后放在更高的隔离级别中解决。 四、MVCC机制篇总结
MVCC多版本并发控制其中的多版本主要依赖Undo-log日志来实现而并发控制则通过表的隐藏字段ReadView快照来实现通过Undo-log日志、隐藏字段、ReadView快照实现了MVCC机制。
