电影网站建站,什么网站上做指甲最便宜,wordpress同步到微信,网站建设中出现的问问题为什么需要MVCC
锁本身就是用于并发控制的#xff0c;那么为什么InnoDB还要引入MVCC#xff0c;读写都加锁不就可以控制住并发吗#xff1f; 锁确实可以#xff0c;但是性能太差。如果是纯粹的锁#xff0c;那么写和写、读和写、读和读之间都是互斥的。如果是读写锁…为什么需要MVCC
锁本身就是用于并发控制的那么为什么InnoDB还要引入MVCC读写都加锁不就可以控制住并发吗 锁确实可以但是性能太差。如果是纯粹的锁那么写和写、读和写、读和读之间都是互斥的。如果是读写锁那么写和写、读和写之间依旧是互斥的。 数据库和一般的应用有一个很大的区别就是数据库即使是读也不能被写阻塞住。 所以数据库要有一种机制避免读写阻塞。在理解了为什么MVCC必不可少后现在你需要进一步了解一个和MVCC紧密关联的概念隔离级别。
隔离级别
数据库的隔离级别是一组规则用来控制并发访问数据库时如何分配、保护和共享资源。不同的隔离级别在不同的并发控制策略之间进行调整从而提供了不同的读写隔离级别和安全性。隔离级别代表了一个事务是否了解别的事务以及了解程度怎么样。 MySQL的隔离级别有四个。
读未提交 Read Uncommitted 是指一个事务可以另外一个事务尚未提交的修改 读已提交 Read Committed 是指一个事务只能看到已经提交的事务的修改。如果在事务执行过程中有别的事务提交了那么事务还是能够看到别的事务最新提交的修改。 可重复读 Repeatable Read 是指在这一个事务内部读同一个数据多次读到的结果都是同一个。这意味着即使在事务执行过程中有别的事务提交这个事务依旧看不到别的事务提交的修改。这是MySQL默认的隔离级别。 串行化 Serializable 是指事务对数据的读写都是串行化的
从上到下隔离性变强了但是性能变差了所以一个提升MySQL性能最简单的方式就是把隔离级别往下调这也是我们的一个亮点方案。
和隔离级别密切相关的概念是脏读、幻读和不可重复读 这三个读异常。
脏读读到了别的事务还没有提交的数据。之所以叫做脏读就是因为未提交数据可能会被回滚掉。不可重复读在一个事务执行过程中对同一行数据读到的结果不同幻读事务执行过程中别的事务插入了新的数据并且提交了然后事务在后续步骤里读到了这个新的数据。 用一个表用来描述隔离级别和三种读异常的关系 理论上可重复读是没有解决幻读的但是因为MySQL因为使用了临键锁因此它的可重复读隔离级别已经解决了幻读问题。
此外还有一个相似的概念快照读和当前读。 快照读就是在事务开始的时候创建了一个数据的快照在整个事务过程中都读这个快照 当前读则是每次都去读最新数据。
MySQL在可重复读这个隔离级别下查询的执行效果和快照读非常接近。
版本链
为了实现MVCCInnoDB引擎给每一行都加了两个额外的字段trx_id和roll_ptr
trx_id事务ID也叫做事务版本号。MVCC里面的V指的是这个数字每一个事务在开始的时候就会获得一个ID然后这个事务内操作的行的事务ID都会被修改为这个事务的IDroll_ptr回滚指针InnoDB通过roll_ptr把每一行的历史版本串联在一起。
实际上InnoDB引擎还隐式地插入了另外一个列row_id如果你没有设置任何主键那么这个列就会被当作主键来使用。但是它其实和MVCC没太大关系所以不需要关注。
下面用一个例子来说明MVCC是如何利用这两个列地。
假设最开始我插入了一行数据我插入数据的这个事务的ID是100那么这个时候数据行看起来是这样的。 假设有一个事务A拿到了ID 101然后把x的值修改为15那么就会变成这样。 这个时候事务A修改后的roll_ptr会指向初始状态的数据。假如现在再来一个事务B拿到ID 102要把数据修改为20那么就会变成下面这样。 这条链就是大名鼎鼎的版本链这个版本链存储在所谓的undolog里。
问题来了假如这个时候我有一个新的事务 C我要读 x 的值那么我该读取 trx_id 为几的数据呢这就涉及到了另外一个和 MVCC 紧密相关的概念Read View
Read View
可以理解为一种可见性规则undolog里存放着历史版本的数据当事务内部要读取数据的时候Read View 就被用来控制这个事务应该读取哪个版本的数据。
Read View 最关键的字段叫做m_ids代表的是当前已经开始但是还没有结束的事务ID也叫做活跃事务ID。 Read View 只用于已提交读和可重复读两个隔离级别它用于这两个隔离级别的不同点就在于什么时候生成Read view
已提交读事务每次发起查询的时候都会重新创建一个新的Read view可重复读事务开始的时候创建Read view
一个很有意思的类比已提交读就像你的渣男朋友你每次见到他他都会换一个新对象而可重复读就是一个痴情男你每次见到他看到的都是他高中时候谈的对象。
Read view与已提交读
在已提交读的隔离级别下每一次查询都会产生一个新的Read view。这意味着在事务执行过程中Read view是在不断变动的。假如说现在已经有三个事务了状态分别是已提交、未提交、未提交。 假如说现在新开了一个事务A分配给它的ID是4。如果这个时候A开始查询x的值那么MySQL会创建一个新的Read view其中m_ids 2,3 。事务A发现最后一个已经提交的事务trx_id1对应的x是1于是事务A读到x1。 这个时候事务2提交了事务A再次读取x这个时候MySQL又会生成一个新的Read viewm_ids3因此事务A会读取到x4
Read view与可重复读
在可重复读的隔离级别下数据库会在事务开始的时候生成一个Read view这意味着整个Read view在事务执行过程中都是稳定不变的。 用前面的例子来说明就是在事务A开始的时候就会创建出来一个Read view m_ids2,3 这个时候事务A去读x的数据毫无疑问读出来都是1 这个时候如果事务2提交了然后事务A想要再去读x的值Read view不会发生变化即m_ids2,3。所以虽然事务2提交了但是事务A不知道这回事因此还是读到x1 万一这时候有一个新事务 ID 5 开始了并且也提交了。那么事务 A 并不会读取这个新事务的数据因为新事务 ID 已经大于事务 A 的 ID 了5 4事务 A 知道这是一个比它还要晚的事务所以会忽略新的事务的修改。
Read View 总结 实际上和Read View相关的概念还有三个
m_up_limit_id 指的是m_ids中的最小值m_low_limit_id 指的是下一个分配的事务IDm_creator_trx_id 当前事务ID m_up_limit_id 在左边而 m_low_limit_id 在右边
面试准备
了解清楚公司数据库的隔离级别如果公司设置的不是默认的隔离级别那么要搞清楚为什么不使用默认的隔离级别。尤其是用了未提交读、串行化两个隔离级别更加要弄清楚。
在面试过程中面试官会出一些很难让人反应过来的问题比如说面试官会口头构造一条版本链。 我现在有三个事务ID 分别是 101、102、103。如果事务 101 已经提交了但是 102、103 还没提交。这个时候我开启了一个事务准备读取数据那么我读到的是哪个事务的数据 如果这时候事务 103 提交了但是 102 还没提交那么会读到谁的呢 第一个问题是事务101 第二个问题需要根据隔离级别来回答了
基本思路
有的时候在面了锁之后将话题引到MVCC问你为什么有了锁还需要MVCC回答的关键词是避免读写阻塞 单纯使用锁的时候并发性能会比较差即使是在读写锁这种机制下读和写依旧是互斥的。而数据库是一个性能非常关键的中间件如果某个线程修改某条数据就让其他线程都不能读到这条数据这种性能损耗是无法接受的。所以InnoDB引擎引入了MVCC就是为了减少读写阻塞。 大部分的时候面试官在问MVCC的时候都直接问你这几个问题
你是否了解MVCCMVCC是什么MySQL的InnoDB引擎是怎么控制数据并发访问的当一个线程在修改数据的时候另外一个线程还能不能读到数据
按照基本定义、实现机制、隔离级别的逻辑顺序来回答 MVCC是MySQL InnoDB引擎用于控制数据并发访问的协议。MVCC主要是借助版本链来实现的。在InnoDB引擎里面每一行都有两个额外的列一个是trx_id代表的是修改这一行数据的事务ID另外一个是roll_ptr代表的是回滚指针。InnoDB通过回滚指针将数据的不同版本串联起来也就是版本链。这些串联起来的历史版本被放到了undolog里面。当某一个事务发起查询的时候MVCC会根据事务的隔离级别来生成不同的Read View从而控制事务查询最终得到的结果。 首先回答里提到了undolog面试官可能追问undolog、redolog或binlog的细节这一部分可以把话题引到下一节课的内容。 其次回答中提到了隔离级别并提到了Read View是和隔离级别有关的东西面试官就会非常深入的问隔离级别的基本定义、MVCC是怎么利用Read View来实现已提交读和可重复读的。
在回答的时候要先解释清楚四个隔离级别和三个读异常然后强调一下InnoDB引擎。 在MySQL的InnoDB引擎里使用了临键锁来解决幻读的问题所以实际上MySQL InnoDB引擎的可重复读隔离级别也没有幻读的问题。一般来说隔离级别越高性能越差所以我之前在公司做的一个很重要的事情就是推动隔离级别降低为已提交读。 这个回答的最后就可以尝试把话题引导到下面的亮点方案中。
亮点方案
重点要描述清楚两方面的内容
推动公司把隔离级别从默认的可重复读降低为已提交读在已提交读的基础上万一需要利用可重复读的特性该怎么办
从前面的内容中你已经知道MySQL 的默认隔离级别是可重复读实际上互联网的很多应用都调整过这个隔离级别降低为已提交读。那么你在面试的时候可以考虑使用这个来作为你的亮点方案。首先你要强调为什么要改。 最开始我来到公司的时候我们的数据库隔离级别都是使用默认的隔离级别也就是可重复读。但其实我们的业务场景很少利用可重复读的特性比如说几乎全部事务内部对某一个数据都是只读一次的。 并且可重复读比已提交读更加容易引起死锁的问题比如说我们之前就出现过一个因为临键锁引发的死锁问题。而且已提交读的性能要比可重复读更好。所以综合之下我就推动公司去调整隔离级别将数据库的默认隔离级别降低为已提交读。 在这种情况下面试官可能会追问你“在调整了事务级别之后万一需要可重复读的特性了你怎么办” 首先你要理解在什么样的场景下你才会需要可重复读这个隔离级别。
你需要在事务中发起两次同样的查询并且你希望两次得到的结果是一样的。你需要避开幻读也就是事务开始之后即便有别的事务插入了数据并且提交了你也不希望读到这个新数据。
但是仔细想想你真的存在这种场景吗或者说你真的没得选以至于一定要使用可重复读这个隔离级别吗 答案是几乎没有。大部分出现可重复读的需求都是因为代码没有写好或者说至少可以通过改造业务来实现。比如说常见的可重复读既然你需要读多次那么自然可以在第一次读完之后缓存起来。
不过幻读是没有办法通过业务改造来解决的。但是在业务层面上幻读一般不会被认为是一个问题原因有两点一是你分不清是不是幻读。比如说你在事务 A 里面读到了一条数据你判断不出来它是在事务 A 开始之前就插入的还是在事务 A 开始之后事务 B 才插入并且提交的。 二是事务提交往往意味着业务已经结束所以读到一个已经提交的事务的数据不会损害业务的正确性。也就是说如果事务A在开始之后事务B才插入数据并且提交那么这个时候事务A完全可以认为事务B所在的整个业务已经结束了所以读出来也没什么问题。
回答的关键词是改造业务 正常来说是不推荐使用可重复读的因为在我们的业务环境下想不到有什么场景非得使用可重复读这个隔离级别。 之前在推动降低隔离级别的时候其实重构过一些业务。这一类业务就是在一个事务里面发起了两个同样的查询比如在UPDATE之后又立刻查询这种查询还必须走主库不然会有主从延迟的问题。 这种业务可以通过缓存第一次查询的数据来避免第二次查询。但是这种改造一般是避不开幻读的。不过在业务上幻读一般不是问题。一方面是业务层面上区分不出来是否是幻读。另外一方面事务提交了往往代表业务已经结束那么发生幻读了业务依旧是正常的。比如说事务 A 读到了事务 B 新插入的数据但是事务 B 本身已经提交了那么事务 A 就认为事务 B 所在的业务已经完结了那么读到了就读到了并不会出什么问题。 兜底的手段是指定隔离级别 万一不能改造业务那么还有一个方法就是直接在创建事务的时候指定隔离级别。我前面调整的都是数据库的默认隔离级别实际上还可以在 Session 或者事务这两个维度上指定隔离级别。
