【MySQL】当前读、快照读、MVCC

  • 当前读:

  select...lock in share mode (共享读锁)
  select...for update
  update , delete , insert

  当前读, 读取的是最新版本, 并且对读取的记录加锁, 阻塞其他事务同时改动相同记录,避免出现安全问题。

  例如,假设要update一条记录,但是另一个事务已经delete这条数据并且commit了,如果不加锁就会产生冲突。所以update的时候肯定要是当前读,得到最新的信息并且锁定相应的记录。

  • 当前读的实现方式:next-key锁(行记录锁+Gap间隙锁)

  间隙锁:只有在Read Repeatable、Serializable隔离级别才有,就是锁定那些范围空间内的数据,假设锁定id>3的数据,id有3,4,5,那么4,5和后面的数字都会被锁定,像6,7...,为什么要这样?因为如果我们不锁定没有的数据,当加入了新的数据id=6,就会出现幻读,间隙锁避免了幻读。

  对主键或唯一索引,如果select查询时where条件全部精确命中(=或者in),这种场景本身就不会出现幻读,所以只会加行记录锁。

  • 快照读

  简单的select操作(不包括 select ... lock in share mode, select ... for update)。    

  Read Committed隔离级别:每次select都生成一个快照读。

  Read Repeatable隔离级别:开启事务后第一个select语句才是快照读的地方,而不是一开启事务就快照读。

  • 快照读的实现方式:undolog和MVCC

  undolog:

  每行除了数据外 还有

  DB_TRX_ID: 6字节DB_TRX_ID字段,表示最后更新的事务id(update,delete,insert)。此外,删除在内部被视为更新,其中行中的特殊位被设置为将其标记为已软删除。
  DB_ROLL_PTR: 7字节回滚指针,指向前一个版本的undolog记录,组成undo链表。如果更新了行,则撤消日志记录包含在更新行之前重建行内容所需的信息。
  DB_ROW_ID: 6字节的DB_ROW_ID字段,包含一个随着新行插入而单调递增的行ID, 当由innodb自动产生聚集索引时,聚集索引会包括这个行ID的值,否则这个行ID不会出现在任何索引中。如果表中没有主键或合适的唯一索引, 也就是无法生成聚簇索引的时候, InnoDB会帮我们自动生成聚集索引, 聚簇索引会使用DB_ROW_ID的值来作为主键; 如果表中有主键或者合适的唯一索引, 那么聚簇索引中也就不会包含 DB_ROW_ID了 。

 

  • insert undo log: 只在事务回滚时需要, 事务提交就可以删掉了。
  • update undo log: 包括update 和 delete , 回滚和快照读 都需要。

  

  多版本并发控制MVCC

  如图,开始只有最下面一行记录,

  当事务1更改该行记录时,会进行如下操作:

  事务1 先用排它锁锁住该行记录(当前读,读到最新数据然后独占),复制到undolog,即图中第二行记录;再更新字段, 把自己的事务id填入DB_TRX_ID, 让回滚指针DB_ROLL_PTR 指向undolog中修改前的原数据(开始只有最下面一行记录)
  事务2操作也是一样, 产生了第三行记录。

原文地址:https://www.cnblogs.com/wwcom123/p/10727194.html

时间: 2024-10-18 23:25:49

【MySQL】当前读、快照读、MVCC的相关文章

别再误解MySQL和「幻读」了

The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is executed twice, but returns a row the second time that was not returned the first time, the

当前读和快照读

innodb的默认事务隔离级别是rr(可重复读).它的实现技术是mvcc.基于版本的控制协议.该技术不仅可以保证innodb的可重复读,而且可以防止幻读.但是它防止的是快照读,也就是读取的数据虽然是一致的,但是数据是历史数据.如何做到保证数据是一致的(也就是一个事务,其内部读取对应某一个数据的时候,数据都是一样的),同时读取的数据是最新的数据.innodb提供了一个间隙锁的技术.也就是结合grap锁与行锁,达到最终目的.当使用索引进行插入的时候,innodb会将当前的节点和上一个节点加锁.这样当

SQL Server已提交读快照隔离级别的设置

如果要把SQL Server数据库事务隔离级别设置为已提交读快照隔离 如果直接运行下面的语句: ALTER Database [mydbname] SET READ_COMMITTED_SNAPSHOT ON 会可能被阻塞很长时间.我这边在正式环境测试过4个小时都没有执行完. 你可以选择运行下面的语句: if(charindex('Microsoft SQL Server 2005',@@version) > 0) begin declare @sql varchar(8000) select

nolock的替代方案-提交读快照隔离[行版本控制]

with(nolock)并意味着没有锁,实际上在查询一张表时,还是有锁,会对对象增加架构锁, 防止表会修改,会对数据库增加共享锁.若使用drop index,则要等到架构锁释放. sql server2005提供了快照隔离和读取已提交快照这两种新的不加锁.无阻塞的事务隔离级别,可使用 快照:每次从数据进行修改时,会在teampdb上存储上一版本 好处: select不要求锁,会大大降低整个库的锁负载量 nolock会读取到未提交事务时修改的数据,而读快照读取的是修改之前的数据,故nolock易读

SQL Server 已提交读快照 测试

原文:SQL Server 已提交读快照 测试 1. 打开数据库 已提交读快照 选项 2. 数据库 已提交读快照 模式下的测试 a) 测试表 Test b) 开启事务1,更新数据C2 = '200'(未提交) BEGIN TRAN UPDATE Test SET C2 = '200' WHERE C1 = 'A' -- COMMIT c) 查询数据(查询没有被阻塞,C2 = '100') SELECT * FROM Test d) 开启事务2,更新数据C2 = '300'(未提交),更新操作被阻

SQL Server 已提交读快照测试

1. 打开数据库 已提交读快照 选项 2. 数据库 已提交读快照 模式下的测试 a) 测试表 Test b) 开启事务1,更新数据C2 = '200'(未提交) BEGIN TRAN UPDATE Test SET C2 = '200' WHERE C1 = 'A' -- COMMIT c) 查询数据(查询没有被阻塞,C2 = '100') SELECT * FROM Test d) 开启事务2,更新数据C2 = '300'(未提交),更新操作被阻塞(等待事务1提交) BEGIN TRAN UP

转:nolock的替代方案-提交读快照隔离[行版本控制]

with(nolock)并意味着没有锁,实际上在查询一张表时,还是有锁,会对对象增加架构锁, 防止表会修改,会对数据库增加共享锁.若使用drop index,则要等到架构锁释放. sql server2005提供了快照隔离和读取已提交快照这两种新的不加锁.无阻塞的事务隔离级别,可使用 快照:每次从数据进行修改时,会在teampdb上存储上一版本 好处: select不要求锁,会大大降低整个库的锁负载量 nolock会读取到未提交事务时修改的数据,而读快照读取的是修改之前的数据,故nolock易读

当前读与快照读

概念 快照读   读取的是记录数据的可见版本(可能是过期的数据),不用加锁 当前读   读取的是记录数据的最新版本,并且当前读返回的记录都会加上锁,保证其他事务不会再并发的修改这条记录   概念说的比较虚,也不好理解,接着举一个例子吧,假设你开启了两个事务,分别是A和B,这里有个张表,user表,里面有四条数据 image.png 1.select快照读(照片)   当你执行select *之后,在A与B事务中都会返回4条一样的数据,这是不用想的,当执行select的时候,innodb默认会执行

Mysql到底是怎么实现MVCC的

Mysql到底是怎么实现MVCC的?这个问题无数人都在问,但google中并无答案,本文尝试从Mysql源码中寻找答案. 在Mysql中MVCC是在Innodb存储引擎中得到支持的,Innodb为每行记录都实现了三个隐藏字段: 6字节的事务ID(DB_TRX_ID ) 7字节的回滚指针(DB_ROLL_PTR) 隐藏的ID 6字节的事物ID用来标识该行所述的事务,7字节的回滚指针需要了解下Innodb的事务模型. 1. Innodb的事务相关概念 为了支持事务,Innbodb引入了下面几个概念: