设计本官方网站广告,网站分为的风格,企业所得税分3个档次,南京模板网站开发MVCC(multi-version-concurrent-control)
MVCC是行锁的一个变种#xff0c;但MVCC在很多情况下它避免了加锁。不是buffer块#xff0c;而是buffer中的记录行。 MVCC (Multi-Version Concurrency Control) (注#xff1a;与MVCC相对的#xff0c;是基于锁的并发控制#x… MVCC(multi-version-concurrent-control)
MVCC是行锁的一个变种但MVCC在很多情况下它避免了加锁。不是buffer块而是buffer中的记录行。 MVCC (Multi-Version Concurrency Control) (注与MVCC相对的是基于锁的并发控制Lock-Based Concurrency Control)是一种基于多版本的并发控制协议只有在InnoDB引擎下存在。
MVCC是为了实现事务的隔离性通过版本号避免同一数据在不同事务间的竞争你可以把它当成基于多版本号的一种乐观锁。当然这种乐观锁只在事务级别提交读和可重复读有效。当前读不用mvcc机制实用锁机制MVCC最大的好处相信也是耳熟能详读不加锁读写不冲突。在读多写少的OLTP应用中读写不冲突是非常重要的极大的增加了系统的并发性能。 不仅是MySQL包括OraclePostgreSQL等其他数据库系统也都实现了MVCC但各自的实现机制不尽相同因为MVCC没有一个统一的实现标准。
可以认为MVCC是行级锁的一个变种但是它在很多情况下避免了加锁操作因此开销更低。虽然实现机制有所不同但大都实现了非阻塞的读操作写操作也只锁定必要的行。
MVCC的实现方式有多种典型的有乐观(optimistic)并发控制 和 悲观(pessimistic)并发控制。
MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作。其他两个隔离级别和MVCC不兼容因为 READ UNCOMMITTED 总是读取最新的数据行而不是符合当前事务版本的数据行。而 SERIALIZABLE 则会对所有读取的行都加锁。 MVCC即多版本并发控制MVCC是一种并发控制的方法一般在数据库管理系统中实现对数据库的并发访问在编程语言中实现事务内存。
MVCC在MySQL InnoDB中的实现主要是为了提高数据库的并发性能用更好的方式去处理读-写冲突做到 即使有读写冲突时也能做到不加锁非阻塞并发读 。
什么是当前读和快照读 当前读 就像 select lock in share mode共享锁select for updateupdateinsertdelete排他锁这些操作都是一种当前读为什么叫当前读因为它读取的记录都是目前数据库中最新的版本读取时还要保证其它并发事务不能修改当前记录不是buffer级别记录级别的所以会对读取数据加锁。
快照读 像不加锁的select操作就是快照读即不加锁的非阻塞读快照读的前提是隔离级别不是串行级别串行级别下的快照读会退化成当前读。串行都是当前读最新buffer无事务不是buffer级别记录级别的加锁
之所以出现快照读的情况是基于提高并发性能的考虑快照读的实现是基于多版本并发控制(MVCC)。
所以我们可以认为MVCC是行锁的一个变种但MVCC在很多情况下它避免了加锁降低了开销既然是基于多版本的所以快照读不一定读到的就是最新版本的记录而是可能为之前的历史版本。
当前读快照读和MVCC的关系 准确的说MVCC多版本并发控制是指“维持一个数据的多个版本使得读写操作没有冲突”这么一个概念听起来特别像我们JAVA中的那个写时复制但这只是一个理想概念。 而在MySQL中实现这么一个MVCC理想概念我们就需要MySQL提供具体的功能去实现它而快照读就是MySQL为我们实现MVCC理想模型的其中一个具体非阻塞读功能不同的快照可以看作不同的数据版本。而相对而言当前读就是悲观锁的具体功能实现。 要说得再细致一点快照读本身也是一个抽象概念再深入研究。MVCC模型在MySQL中的具体实现则是由四个隐式字段undo日志read view 等去完成的。 MVCC能解决什么问题好处是什么 数据库并发场景 当前假设有三种分别为
读-读不存在任何问题也不需要并发控制。 读-写有线程安全问题会体现事务隔离性问题也就是可能遇到脏读不可重复读幻读等。 写-写有线程安全问题可能会存在更新丢失问题比如第一类更新丢失第二类更新丢失也会造成一些事务隔离性问题的出现。 MVCC带来的好处是 **多版本并发控制MVCC**是一种用来解决 读-写 冲突的无所并发控制也就是为事务分配单向增长的时间戳为每个修改保存一个版本版本与事务时间戳关联也就是每个事务都有一个对应版本的快照快照版本按照单向增长的时间戳来决定先后顺序。
在这样的情况下读操作我们只读该事务开始前的数据库快照并不去读取正在修改的数据我们读取事务开始前的最新版本。
所以解决了数据库在并发读取时的问题即可以做到在读操作时不用阻塞写操作写操作也不用阻塞读操作提高了数据库并发读写的性能同时还可以解决脏读不可重复读幻读等事务隔离级别带来的问题。但不能解决更新丢失问题。
小结一下 总之MVCC就是因为大牛们不满意只让数据库采用悲观锁这些性能不佳的形式去解决读-写冲突问题而提出的解决方案所以在数据库中因为有了MVCC所以我们可以形成两个组合
MVCC 悲观锁 MVCC解决读写冲突悲观锁解决写-写冲突。 MVCC 乐观锁 MVCC解决读写冲突乐观锁解决写-写冲突。(Tidb之类new sql ) MVCC的实现原理 MVCC的目的就是多版本的并发控制在数据库中的实现就是为了解决读-写冲突的问题它的实现原理主要是依赖记录中的 3个隐式字段、undo日志、read view 来实现的。
隐式字段 每行记录除了我们自定义的字段外还有数据库隐式定义的DB_TRXID, DB_ROLL, DB_ROW_ID等字段。
DB_ROW_ID 6byte隐含的自增ID隐藏主键如果数据表没有主键InnoDB会自动以DB_ROW_ID生成一个聚簇索引。 DB_TRX_ID 6byte最近修改修改、插入事务ID记录创建这条记录以及最后一次修改该记录的事务的ID是一个指针。 DB_ROLL_PTR 7byte回滚指针指向这条记录的上一个版本上一个版本存储于rollback segment里。 DELETED_BIT 1byte记录被更新或删除并不代表真的删除而是删除flag变了相当于记录一次逻辑删除。 就拿上图来解释这几个字段DB_ROW_ID 是数据库默认为该行记录生成的唯一隐式主键DB_TRX_ID 是当前操作该条记录的事务的IDDB_ROLL_PTR 是一个回滚指针用于配合 undo日志指向该条记录的上一个版本DELETED_FLAG 字段没有展示出来。不是放在页头的 UNDO日志 InnoDB把这些为了回滚而记录的这些东西称之为 undo log。
值得注意的是由于查询操作SELECT并不会修改任何用户记录所以在查询操作时并不需要记录相应的 undo log。
undo log 主要分为以下三种 insert undo log 插入一条记录时至少把这条记录的主键记录下来之后回滚的时候只需要把主键对应的记录删除即可。 update undo log 修改一条记录时至少要把修改这条记录前的旧值都记录下来在回滚的时候再把这条记录的值更新为旧值就好了。 delete undo log 删除一条记录时至少要把这条记录中的全部内容都记录下来这样在之后回滚的时候再重新将这些内容组成的记录插入到表中就好了。 删除操作都只是设置一下老记录的 DELETE_BIT并不是真正将其删除类似于数据库提供的专门的逻辑删除。
-----undo log中存放的一个是sql语句还有改变的记录变化。到时undo时直接用undo中的一段记录替换buffer中的一段记录。不会真正去执行sql 进行undo 为了节省磁盘空间InnoDB有专门的 purge清除线程来清理 DELETED_BIT 为 true 的记录。 为了不影响MVCC的正常工作purge线程自己也维护了一个 read view这个 read view 相当于当前系统中最老活跃的事务的 read view。 如果某个记录的 DELETED_BIT 为 true并且 DB_TRX_ID最后一个操作的事务ID 相对于 purge线程的 read view 可见那么这条记录一定是可以被安全清除的。 对 MVCC 有实质上帮助的是 update undo logundo log 实际上就是存在于 rollback segment 中的旧纪录链。 buffer中的一段代码 链
说了这么多云里雾里的我们来看一个例子
比如一个事务往 persion表 中插入了一条新纪录记录如下name jerryage 24 隐式主键 1事务ID和回滚指针都假设为 NULL 现在来了另一个事务1对该记录的 name 做出了修改改为 tom 在该 事务1 修改该行记录数据的同时数据库会先对该行加排他锁InnoDB引擎会自动对DML语言影响的记录上写锁|独占锁。 上锁完毕后将该行数据拷贝到 undo log 中作为旧记录即在 undo log 中有当前行的拷贝副本。 拷贝完毕后修改该行的 name 为 tom并且修改隐藏字段的 事务ID 为当前 事务1的ID这里我们默认是从1开始递增回滚指针指向拷贝到 undo log 的副本记录即表示我的上一个版本就是他。事务提交后释放锁。 又来了一个事务2修改persion表的同一个记录将 age 修改为 30岁
在事务2修改该行数据之前数据库继续给他上排他锁。 上锁完毕之后把该行数据拷贝到 undo log 中作为旧记录发现操作的这行记录已经有undo log 的记录了那么最新的旧数据作为链表的表头插在这行记录的 undo log 日志的最前面。 修改该行age为30岁并且修改隐藏字段的事务ID为当前事务2的ID那就是2回滚指针指向刚刚拷贝到 undo log 的副本记录。 事务提交释放锁。 ----图中事务id也是很复杂的 从上面几个例子可以看出不同事物或者相同事务对同一个记录的修改会导致该记录的 undo log 成为一条版本记录链。undo log 的链首就是最新的旧记录尾部就是最旧的记录当然就像之前所说的该 undo log 的节点可能是会被 purge线程 清除掉的像图中的第一条 insert undo log 其实在事务提交之后可能就被删除丢失了不过这里为了演示所以还放在这里假设没被清除。 Oracle 没有隐藏字段是通过ITL表中 以及undo segment header中找到的 PG是直接添加一个元组和时间类似于KV数据库多版本。 Read View读视图 什么是 Read View说白了 Read View 就是事务进行快照读操作的时候生产的读视图在当前事务执行快照读的那一刻会生成数据库系统当前的一个快照记录并维护系统当前活跃事务的ID当每个事务开启时都会被分配一个ID这个ID是默认递增的所以事务越新ID越大。读本身不是事务不产生事务ID读取的是系统那一刻的ID
所以我们可以知道 Read View 主要是用来做可见性判断的即当我们某个事物执行快照读的时候对读取的该记录创建一个 Read View 视图把它当作条件用来判断当前事务能够看到哪个版本的数据既可能是当前最新的数据也就是该快照也可能是该行记录的 undo log 日志里的某个版本的数据。
Read View 遵循一个可见性算法
事务ID查询就不会新增只有DML语言才会导致事务ID增加。
主要是将被修改的数据的最新记录中的 DB_TRX_ID当前事务ID取出来与系统当前其它活跃事务的ID去对比由 Read View 维护如果 DB_TRX_ID 跟 Read View 的属性做了某些比较之后不符合可见性那就通过 DB_ROLL_PRT 回滚指针去取出 undo log 中的 DB_TRX_ID 再比较也就是说遍历 undo log 链表的 DB_TRX_ID 找到特定条件的事务ID的版本那么这个 DB_TRX_ID 所在的旧记录就是当前事务能看见的最新老版本。找不到的时候就是快照过旧。。。。。。
那么这个判断条件是什么呢
如上他是一段 MySQL 判断可见性的一段源码。即 changes_visible 方法不完全但是能看出大致逻辑该方法展示了我们拿 DB_TRX_ID 去跟 Read View 某些属性进行怎么样的比较。
在介绍前我们先简化一下 Read View 我们可以把 Read View 简单的理解成有三个全局属性
trx_list未提交事务 ID 列表用来维护 Read View 生成时刻系统正处于活跃状态的事务ID。 up_limit_id记录 trx_list 事务ID列表中 最小的ID也就是最初修改该记录的事务。 low_limit_idRead View 生成时刻系统尚未分配的下一个事务ID也就是等于**目前出现过的最大事务ID 1**。 方法大致流程对比上面代码 首先判断 DB_TRX_ID up_limit_id
大于进入下一个判断。 小于则当前事务能看到 DB_TRX_ID 所在记录。 判断 DB_TRX_ID low_limit_id
大于代表 DB_TRX_ID 所在的记录是在 Read View 生成之后才出现的那对当前事务肯定不可见。 小于进入下一个判断。 判断 DB_TRX_ID 是否在活跃事务中 trx_list.contains(DB_TRX_ID)
在代表 Read View 生成的时候你这个事务还在活跃状态并没有 commit你修改的数据我当前的事务是看不见的RR隔离级别。 不在说明你这个事务在 Read View 生成之前就已经 commit 了你修改的结果我当前事务是看得见的。 可以这样理解 Read View 不应该让当前事务看到的记录版本这些记录版本对应的事务ID都在Read View 中。 以 Repeatable Read RR隔离级别举个例子吧要求读一个值一直读都是同一个值 这种隔离级别下开启事务的时候开启一个 Read View 在当前事务执行的整个过程中都用这个 Read View。(不用显式开启事务) 当前 事务ID 10ReadView 就是48, 10因为当前事务10正在执行所以自己也活跃此时 up_limit_id4low_limit_id11。 如果 **当前事务10 **读到一个数据的 事务ID 1小于 活跃列表的最小值up_limit_id4可见。 为什么 因为在 事务10 开启的时候生成的 Read View 除了4810其他事务都已经提交了不处于活跃状态了所以事务1的版本 事务4的版本以及5、6、7、9都是肯定在我开启的时候已经提交了事务ID单调递增。 所以这些版本的的数据再怎么读都不会变可以放心的读。 但如果我读到一个数据的 事务ID 12说明他在我创建 Read View 之后提交的我不应该看见这个值应该去 undo log 里找这个数据的前面的版本如果找到 事务ID 4的版本或者 事务ID (5、6、7、9)的版本 都是安全的可以读。 如果我读到一个数据 事务ID在活跃列表的范围内 如果当前事务就是活跃的事务之一比如说是8说明这个数据在我开启事务之后才被其它活跃事务更改提交或未提交那么这个我不能看见应该去 undo log 中找上一个版本来读假设说是 77也是在这个活跃范围里但是并不是活跃事务之一这个版本是在当前事务开启事务之前由事务7提交的所以这个版本可见。 再举个读已提交的例子
在这个隔离级别是每次读都采用新的 Read View。 事务10 开启。 读一个数据事务ID 9假设此时Read View 中 活跃事务ID 4810按照规则可见。 过一会再读这个数据发现此时 事务ID 11而此时活跃事务ID 4810但是因为开启了新的 Read View low_limit_idRead View 生成时刻系统尚未分配的下一个事务ID也就是等于**目前出现过的最大事务ID 1**。当前系统最大事务ID 11(因为我们已经读到11了嘛)根据判断规则事务11不在活跃ID列表并且 事务11ID 11 (low_limit_id 12)RC这次需要新生成read view 所以low_limit_id 变大了不同于RR所以可见。这回就读到了这个数据的新版本了。 同一个session 两次读的数据是不一样的 --------------------------------------- MVCC 都是基于快照的 Read View和快照Snapshot 事务快照是用来存储数据库的事务运行情况。一个事务快照的创建过程可以概括为
查看当前所有的未提交并活跃的事务存储在数组中 选取未提交并活跃的事务中最小的XID记录在快照的xmin中 选取所有已提交事务中最大的XID加1后记录在xmax中 Read View 主要是用来做可见性判断的创建一个新事务时copy一份当前系统中的活跃事务列表。意思是当前不应该被本事务看到的其他事务id列表。
对于Read View快照的生成时机也非常关键正是因为生成时机的不同造成了RCRR两种隔离级别的不同可见性
在innodb中(默认repeatable read级别)事务在begin/start transaction之后的第一条select读操作后会创建一个快照(Read View)将当前系统中活跃的其他事务记录记录起来 在innodb中(read committed级别)事务中每条select语句都会创建一个快照(Read View) 整体流程 说了这么多我们在了解了 隐式字段、undo log、Read View 的概念之后。就可以来看看MVCC 的具体实现流程大致是什么样的了。
我们可以模拟一下
当 事务2 对某行数据执行了快照读数据库为该行数据生成一个 Read View 读视图假设当前事务ID为2此时还有事务1和事务3在活跃状态中事务4在事务2快照读前一刻提交了更新所以 Read View 记录了系统当前活跃事务13的ID维护在一个列表上假设我们称这个列表为 trx_list: … … … ReadView 不仅仅会通过一个列表 trx_list 来维护事务2执行快照读那刻系统中正在活跃的事务ID还会有两个属性 up_limit_idlow_limit_id所以在这里的例子中up_limit_id 1, low_limit_id 41 5trx_list集合的值是13Read View 如下图。 我们的例子中只有事务4修改过该行记录并在事务2 执行快照读前就提交了事务。
所以当前该行数据的 undo log 就如下图所示。 我们的事务2在快照读该行记录的时候就会拿该行记录的 DB_TRX_ID 去和 up_limit_idlow_limit_id 和 trx_list活跃事务ID列表进行比较判断当前事务2能看到的记录是哪个版本。 MVCC相关的问题 RR是如何在RC级的基础上解决不可重复读的 当前读和快照读在 RR级别 下的区别 在表第二部分中为什么事务B在事务A的提交后快照读和当前读都是400呢 这里与第一个表的唯一区别仅仅是表一的事务A修改金额前快照读过一次金额数据而表二的事务B在事务A提交前并没进行过快照读。
所以我们知道事务中快照读的结果非常依赖事务首次出现快照读的地方即某个事务中首次出现快照读的地方十分的关键它可以决定该事务后续快照读结果的能力。
我们这里测试的是更新同时删除和更新也是一样的如果事务B的快照读是在事务A操作之后进行的事务B的快照读也是能读取到最新的数据的。 -------是不是RR读会导致数据别的事务数据更新丢失呢
如上图虽然快照读的数据不一样但是当前读的数据都是别的事务更新后的记录不存在RR和RC模式下导致数据更新丢失。 RC,RR级别下的InnoDB快照读有什么不同 正式因为 Read View 的生成时间不同。
在 RR 级别下的某个事务对某条记录的第一次快照读会创建一个快照以及 Read View记录当前系统中活跃的其它事务此后在调用快照读的时候还是用的同一个 Read View所以只要当前事务在其它事务提交更新之前使用过快照读那么之后的快照读使用的都是同一个 Read View所以对之后的修改不可见。 即 RR 级别下快照读生成 Read View 时Read View 会记录所有当前其它所有活跃事务的快照这些事务的修改对于当前事务都是不可见的而早于 Read View 创建的事务所作的修改均可见。 在 RC 级别下事务中每次快照都都会生成一个新的 Read View 和最新快照这就是我们在 RC级别下的事务中可以看到别的事务提交更新的原因。 反正总而言之就是 RC 隔离级别 下每个快照读都会生成新的 Read View 以及快照而在 RR隔离级 别下则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。
