MYSQL的锁

根据加锁的范围,MYSQL里面的锁大致可分为全局锁,表级锁和行锁

全局锁会让整个库处于只读状态,一个典型场景就是做全库逻辑备份。

表锁一般是在数据库引擎不支持行锁的时候才会被用到的。如果你发现你的应用程序里有 lock tables 这样的语句,可能时使用MyISAM引擎导致,那要安排升级换引擎。

行锁是引擎层自己实现的,行锁就是针对数据库行记录的锁,比如事务 A 更新了一行,而这时候事务 B 也要更新同一行,则必须等事务 A 的操作完成后才能进行更新。行锁是在执行的时候加,事务提交的时候释放如果你的事务中需要锁多个行,要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。

事务与行锁的关系

在讲MYSQL事务隔离的时候,事务T启动会创建视图read-view,之后即使其他事务修改了数据,事务T看到的数据依然是和启动时相同

但是Innodb引擎的行锁,事务更新一行,如果刚好其他事务持有这一行的行锁,这个事务不能更新这行数据,会被锁住,那么等到这个事务自己获取到行锁要更新数据的时候,它读到的值又是什么呢?

mysql> CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `k` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t(id, k) values(1,1),(2,2);
事务A 事务B 事务C
start transaction with consistent snapshot
start transaction with consistent snapshot
update t set k = k+1 where id= 1
update t set k = k+1 where id= 1;select k from t where id =1;
select k from t where id =1 ;comit;
comit;
事务 C 没有显式地使用 begin/commit,表示这个 update 语句本身就是一个事务,语句完成的时候会自动提交
在 MySQL 里,有两个“视图”的概念:
  • 一种是虚拟表,通过CREATE VIEW以及查询语句生成
  • 另一个是 InnoDB 在实现 MVCC 时用到的一致性读视图,用于支持 RC(Read Committed,读提交)和 RR(Repeatable Read,可重复读)隔离级别的实现。

在 MVCC 里是怎么工作的?

在可重复读隔离级别下,事务在启动的时候就“拍了个快照”。注意,这个快照是基于整库的。

InnoDB 里面每个事务有一个唯一的事务 ID,叫作 transaction id。是按申请顺序严格递增的。

每次事务更新数据的时候,都会生成一个新的数据版本,并且把 transaction id 赋值给这个数据版本的事务 ID,记为 row trx_id。在新的数据版本中,指向旧版本的指针。
MYSQL的锁_第1张图片
可重复读的定义,一个事务启动的时候,能够看到所有已经提交的事务结果。但是之后,这个事务执行期间,其他事务的更新对它不可见。数据版本可不可见的关键在于是否是我当前事务开启之前生成的,因此,InnoDB 为每个事务构造了一个数组,用来保存这个事务启动瞬间,当前启动但是没有提交的trx_id。他的左侧数组最小值,右侧时最大值+1。

  • 小于这个最小值表示已提交事务,或者当前事务生成的,这部分数据可见。
  • 大于等于最大值表示时将来事务生成的,这部分数据不可见。
  • 如果trx_id在这个数组区间范围内
    1> 若 row trx_id 在数组中,表示这个版本是由还没提交的事务生成的,不可见;
    2> 若 row trx_id 不在数组中,表示这个版本是已经提交了的事务生成的,可见。

在这个范围里面并不意味这这个范围里有这个值,比如[1,2,3,5],4在这个数组1-5的范围里,却没在这个数组里面。换句话说,小于最小值的一定可见,但是可见的不一定小于这个最小值。

对于上面的状态变更来说,如果有一个事务,它的低水位是 18,那么当它访问这一行数据时,就会从 V4 通过 U3 计算出 V3,所以在它看来,这一行的值是 11。

假设表格

  1. 事务 A 开始前,系统里面只有一个活跃事务 ID 是 99;
  2. 事务 A、B、C 的版本号分别是 100、101、102,且当前系统里只有这四个事务;
  3. 三个事务开始前,(1,1)这一行数据的 row trx_id 是 90。

这样,事务 A 的视图数组就是[99,100], 事务 B 的视图数组是[99,100,101], 事务 C 的视图数组是[99,100,101,102]
第一个有效更新是事务 C,把数据从 (1,1) 改成了 (1,2)。这时候,这个数据的最新版本的 row trx_id 是 102,而 90 这个版本已经成为了历史版本。

第二个有效更新是事务 B,把数据从 (1,2) 改成了 (1,3)。这时候,这个数据的最新版本(即 row trx_id)是 101,而 102 又成为了历史版本。更新的时候是当前读,读取最新已提交的事务,他的事务id是101,可以读取到更新的数据。

在事务 A 查询的时候,其实事务 B 还没有提交,但是它生成的 (1,3) 这个版本已经变成当前版本了
现在事务 A 要来读数据了,它的视图数组是[99,100]

  • 找到 (1,3) 的时候,判断出 row trx_id=101,比高水位大,处于红色区域,不可见;
  • 接着,找到上一个历史版本,一看 row trx_id=102,比高水位大,处于红色区域,不可见;
  • 再往前找,终于找到了(1,1),它的 row trx_id=90,比低水位小,处于绿色区域,可见。

一个数据版本,对于一个事务视图来说,除了自己的更新总是可见以外,有三种情况:

  • 版本未提交,不可见;
  • 版本已提交,但是是在视图创建后提交的,不可见;
  • 版本已提交,而且是在视图创建前提交的,可见。

按照这个逻辑来的话

  • (1,3) 还没提交,属于情况 1,不可见;
  • (1,2) 虽然提交了,但是是在视图数组创建之后提交的,属于情况 2,不可见;
  • 1,1) 是在视图数组创建之前提交的,可见。

更新逻辑

要去更新数据的时候,就不能再在历史版本上更新了,否则事务 C 的更新就丢失了。因此,事务 B 此时的 set k=k+1 是在(1,2)的基础上进行的操作。
更新数据都是先读后写的,而这个读,只能读当前的值,称为“当前读”。

因此,在更新的时候,当前读拿到的数据是 (1,2),更新后生成了新版本的数据 (1,3),这个新版本的 row trx_id 是 101。所以,在执行事务 B 查询语句的时候,一看自己的版本号是 101,最新数据的版本号也是 101,是自己的更新,可以直接使用,所以查询得到的 k 的值是 3。

这里我们提到了一个概念,叫作当前读。其实,除了 update 语句外,select 语句如果加锁,也是当前读。

如果把事务 A 的查询语句 select * from t where id=1 修改一下,加上 lock in share mode 或 for update,也都可以读到版本号是 101 的数据,返回的 k 的值是 3。下面这两个 select 语句,就是分别加了读锁(S 锁,共享锁)和写锁(X 锁,排他锁)。
MYSQL的锁_第2张图片
事务 C’的不同是,更新后并没有马上提交,在它提交前,事务 B 的更新语句先发起了。前面说过了,虽然事务 C’还没提交,但是 (1,2) 这个版本也已经生成了,并且是当前的最新版本。那么,事务 B 的更新语句会怎么处理呢?

事务 C’没提交,也就是说 (1,2) 这个版本上的写锁还没释放。而事务 B 是当前读,必须要读最新版本,而且必须加锁,因此就被锁住了,必须等到事务 C’释放这个锁,才能继续它的当前读。

一致性读依赖mvcc快照,利用事务id递增特性,来做读取数据时历史版本的选择;当前读实际上是由行锁来实现的,持有行锁的更新操作才能进行当前读,否则更新操作会阻塞

而读提交的逻辑和可重复读的逻辑类似,它们最主要的区别是:

  • 在可重复读隔离级别下,只需要在事务开始的时候创建一致性视图,之后事务里的其他查询都共用这个一致性视图;
  • 在读提交隔离级别下,每一个语句执行前都会重新算出一个新的视图。

总之

InnoDB 的行数据有多个版本,每个数据版本有自己的 row trx_id,每个事务或者语句有自己的一致性视图。普通查询语句是一致性读,一致性读会根据 row trx_id 和一致性视图确定数据版本的可见性。对于可重复读,查询只承认在事务启动前就已经提交完成的数据;对于读提交,查询只承认在语句启动前就已经提交完成的数据;

你可能感兴趣的:(关系型数据库,mysql,数据库,锁,mvcc)