：切！这谁没听过，不就是多版本并发控制么~
早在亘古时期，修真界就流传着一门mysql功法，将其修至小乘境界，足以纵横一方。。。不乏也有走火入魔者，为祸一方~
Serializable篇
强制事务排序，串行化执行事务。技能之间不存在冲突，就是滚键盘~能不能再快点呢，技能前摇那么长，一次性放俩多好^_^
Read Uncommitted篇
某个不知名大牛路过
你这样搞一下试试：
| 事务1 | 事务2 |
| select * from table where key = 1; | |
| update table set name=”da niu” where key = 1; | |
| select * from table where key = 1; |
看到了没，事务1第一次查询的结果和第二次查询的结果还能一样吗，this is 脏读！
Read Committed篇
原来这就是脏读啊，那我等到事务2提交之后再读，不就ok了吗^_^
| 事务1 | 事务2 |
| select * from table where key = 1; | |
| update table set name=”da niu” where key = 1; | |
| commit | |
| select * from table where key = 1; |
你能说事务1第二次读出来的数据是脏的吗？不能。但是事务一两次读取的数据结果仍然不同，这叫做不可重复读问题。
Repeatable Read篇
这还怎么搞。。。
据说是有个头秃哥，搞了叫Read View个东西出来。Read View可以认为是数据库的一个内部快照，根据事务的隔离级别，决定在事务开始时，该事务能看到什么信息。就是说通过Read View，事务可以知道此时此刻能看到哪个版本的数据记录（有可能不是最新版本的，也有可能是最新版本的）。可重复读、读已提交、读未提交，这几个隔离级别都会使用Read View。
ReadView中主要包含几个比较重要的字段：
| creator_trx_id | 创建Read View事务的id |
| trx_ids | 生成Read View时活跃的事务id集合 |
| up_limit_id | trx_ids中最小的事务id |
| low_limit_id | 生成Read View时下一个可分配的事务id |
有了这些id信息，即使事务2已提交的情况下，也不会出现可重复读的问题了：
| 事务1 | 事务2 |
| select * from table where key = 1;（获取Read View） | |
| update table set name=”da niu” where key = 1; | |
| commit | |
| select * from table where key = 1;（获取Read View） |
第一次查找获取Read View，当前事务id为0，该行数据的trx_id小于事务1Read View中的up_limit_id，即该行数据为事务1创建之前产生的，故而对事务1可见；
第二次查找，该行数据的trx_id被事务2改为了自己的事务id，使得trx_id在事务1Read View的trx_ids中，说明改行数据由创建事务1时的其它活跃事务更新过，故而使其对事务1不可见；
：数据就没。。没了？
当然不会，还记得undo log吗，记录了数据库操作的执行逻辑。我们对这行数据再做一次相反的执行逻辑，就能拿到修改前的数据了^_^
类似的，如果在事务1创建之后，又有事务3被创建，并修改了key=1的数据，则该行记录的trx_id大于等于事务1Read View中的low_limit_id，也可以知晓当前数据被修改过来。继续根据undo log恢复以前版本的数据即可。
这就是多版本并发控制了。。。
幻读篇
那幻读又是啥呢？？
前面说了不可重复读的问题，是说同一个事务中，多次查询同一条记录，查询结果不同的问题；
幻读其实也很简单，说的是同一个事务中，查询多次，查询结果记录条数不一致的问题；
明白了吧，一个是说记录本身的内容发生变化，另一个说的是记录的条数。
显然，通过MVCC，也能解决幻读的问题了
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
相关推荐: 技术分享 | 如何编写同时兼容 Vue2 和 Vue3 的代码?
LigaAI 的评论编辑器、附件展示以及富文本编辑器都支持在 Vue2（Web）与 Vue3（VSCode、lDEA）中使用。这样不仅可以在不同 Vue 版本的工程中间共享代码，还能为后续升级 Vue3 减少一定阻碍。 那么，同时兼容 Vue2 与 Vue3 …
