锁
并发事务可能出现的情况:
-
读-读事务并发:此时是没有问题的,读操作不会对记录又任何影响。
-
写-写事务并发:并发事务相继对相同的记录做出改动,因为写-写并发可能会产生脏写的情况,但是没有一个隔离级别允许脏写的情况发生。MySQL使用锁的机制来控制并发情况下让事务对一条记录进行排队修改,只有对记录修改的事务提交了才能让下一个事务对记录进行修改。
当第一个事务尝试对一条记录进行修改。会和记录行关联一个锁结构。
trx信息: 代表锁结构是哪个事务产生的。
is_waiting:false代表拥有记录的修改权,true表示等待锁资源释放。
当第二个事务尝试获得锁,失败也会创建一个锁结构将is_waiting置为true,并填入事务信息,加入记录的锁结构中。
当第一个事务提交结束释放锁资源,并会唤醒下一个事务将其等待状态设置为false,让其其获得锁资源。
- 读-写事务并发:有两种解决方案
- MVCC(多版本并发控制) + 加锁。即上文我们说过MVCC只能用作查询数据,所以我们使用MVCC来解决并发下事务对记录修改同时的读取不出现脏读、不可重复读和幻读。写操作就是用加锁的方式来进行控制。
- 读、写都使用加锁。这样子读写的话,读和写都要进行加锁,相当于读和写操作之间要像写和写一样进行排队。
一致性读
事务利用MVCC进行读取操作可以被称为一致性读、一致性无锁读又或者快照读。一致性读不会产生加锁操作。MVCC我们之前文章都讲过
锁定读
就是我们读写都是用加锁的操作。
学习Java的JUC的时候,对于读写锁就是差不多的。
- 共享锁 Shared Locks,简称S锁。要读取一条记录时,需要先获取S锁
- 独占锁 Exclusive Locks,简称X锁。当我们需要更改一条记录时,需要获取记录的X锁。
S锁是可以共享的,即多个事务之间共同获取S锁。但是X锁只能被一个事务拥有,直到事务提交然后才能释放。
不同写操作加锁过程
- delete,会先获取记录的X锁,然后delete_mark 为1,然后提交事务释放锁,放入垃圾链表就OK。
- update
- 如果没更新主键,且更新后数据行各列的大小不发生改变,就直接获取X锁,然后更新数据即可。
- 如果没更新主键,且更新后数据行各列的大小发生改变,先获取记录的X锁,然后将其彻底删除,然后插入更新的记录,新插入的记录由隐式锁进行保护。
- 如果更新了主键,就直接先获取X锁,然后先delete的流程来一下,然后insert的流程来一下,都是加的X锁。
- insert,直接插入新数据,由隐式锁来保证并发事务安全。
多粒度锁
上面说的都是行锁,粒度较细,我们还可以加一个粒度较大的锁,表级锁。
- 共享锁,简称S锁,对表加S锁,其他事务可以继续对表或者行加S锁。但是如果想对表加X锁,或者表内的行加X锁,就需要进行排队等待表的S锁释放。
- 独占锁,简称X锁,对表加X锁,其他事务就不能对表或者行加S锁或X锁了,只能排队。
但是会出现一种情况,就是表内行加了行级锁,但是我们想对表加表级锁,我们怎么才能知道表内有行级锁呢?不能一条一条遍历吧。
- 意向共享锁,简称IS锁,当有事务需要对一条行记录加S锁时,先对表加一个IS锁。
- 意向独占锁,简称IX锁,当有事务需要对一条行记录加X锁时,先对表加一个IX锁。
IS锁和IX锁的作用就是为了让我们快速知道,表内行记录中是否有加了锁,是否能加表级锁。
Innodb中的锁
表级锁
- S锁,X锁
- IS锁,IX锁
- AUTO_INC锁,这个锁是用在自增字段的自增当中的。
- 如果我们不能确定插入的数量,即当我们使用insert … select 、replace … select、load data等语句,我们无法确定插入的条数是多少,innodb会使用AUTO_INC锁。这个锁是会在表的层面进行加锁,然后会对插入的每条记录进行分配一个自增值。
- 如果我们是能够确定的插入数量,比如insert into x(a) values(‘ss’),(‘dd’);我们可以确定插入的记录是两条。innodb就会采用一个轻量级锁,在为插入语句分配好这个自增列的值后,就会将其释放。
在innodb中维护了一个系统变量innodb_autoinc_lock_mode的变量。
当值为0时就是直接采用AUTO_INC锁,不管确不确定。
当值为1时就是采用两种混合的方式,也就是上述的方式。
当值为2时就是一律采用轻量级锁的方式,可能会造成不同事务的自增列产生的值是交叉的,在主从中是不安全的。不是很理解,没有弄过主从。
行级锁
-
Record Locks:当我们要对某个数据行进行操作,我们就会向数据行中加入这个锁。官方命名:LOCK_REC_NOT_GAP。分为S锁和X锁这种类型的锁。解决了并发事务之间对一条记录的读取和修改。可以解决脏写、脏读、不可重复读。
-
Gap Locks:但是出现幻读怎么解决呢?Gap锁就是为了解决幻读。Gap锁能够防止当前记录和前一个记录之间的间隙不能插入新数据。当新数据发现下一条数据有gap锁,就不会执行插入。
我们要让查询的区间不要让其他事务进行插入数据,以防止出现幻读的情况。就会在第一次查询的时候,比如我们查询记录(2,8)就会在8号记录加一个gap锁,这样如果我们插入4号记录就无法插入。如果我们要控制(2,+∞),就会在数据页的Supremun的数据行加入gap锁。
-
key-next Locks:就是Record和Gap锁的合体,就能控制当前行,并且当前行和前一条的数据行之间的间隙不能插入新数据。
-
Insert Intention Locks: 可以叫做插入意向锁,就是当前如果记录的下一条有gap或key-next锁,就不能插入,此时就会在内存中生成一个锁结构,表示某个间隙想要插入新纪录,正在等待,保存在下一条的数据行中。
插入意向锁就是JUC的一个非公平的AQS啊,就是他不会阻止别的事务继续获得数据行的其他锁,就是这个插入意向锁可能会一直一直等下去。
-
隐式锁。即我们上面讲的,在事务进行插入的时候如果有gap锁就会加个插入意向锁事务进入等待状态,但是如果没有的话,我们就会直接进行插入。导致的结果就是什么,我们插入的数据没有进行加锁保护,这时其他事务的可以直接select或者更新,直接导致脏读,或者脏写。
幻读已经被Gap锁解决了所以不会出现哈,这里是在可以插入的时候可能出现的错误,因为如果有Gap说明别的事务可能会读取数据,不能插入,只有提交了Gap锁取消了才能进行插入,隐式锁是在这时候发挥作用。
所以在数据行插入到页中时,会判断插入数据行的事务的trx_id是否还是活跃的状态,如果还是活跃事务,就会为当前插入的数据行创建一个X锁。如果不活跃了,表示事务已经提交就可以放心去改和去查了。
在聚簇索引中就是这个流程,但是在二级索引中数据行没有维护一个trx_id,我们就需要判断二级索引中维护的PAGE_MAX_TRX_ID即最大修改二级索引的事务号,如果小于最小活跃事务ID,就可以放心改了,否则需要回表然后进行一遍聚簇索引的流程。???