欢迎大家关注 github.com/hsfxuebao ,希望对大家有所帮助,要是觉得可以的话麻烦给点一下Star哈
事务的 隔离性
由 锁
来实现。
1. 概述
锁
是计算机协调多个进程或线程并发访问某一资源的机制
。在程序开发中会存在多线程同步的问题,当多个线程并发访问某个数据的时候,尤其是针对一些海敏感的数据(比如订单、金额等),我们就需要保证这个数据在任何时刻最多只有一个线程
在访问,保证数据的完整性
和一致性
。在开发过程中加锁是为了保证数据的一致性,这个
思想在数据库领域中同样很重要。
在数据库中,除传统的计算资源(如CPU、RAM、I/O等)的争用以外,数据也是一种供许多用户共享的资源。
为保证数据的一致性,需要对 并发操作进行控制
,因此产生了 锁。
同时 锁机制
也为实现MySQL的各个隔离级别提供了保证。
锁冲突
也是影响数据库 并发访问性能 的一个重要因素。所以锁对数据库而言显得尤其重要,也更加复杂。
2. MySQL并发事务访问相同记录
并发事务访问相同记录的情况大致可以划分为3种:
2.1 读-读情况
读-读
情况,即并发事务相继 读取相同的记录
。读取操作本身不会对记录有任何影响,并不会引起什么问题,所以允许这种情况的发生。
2.2 写-写情况
写-写
情况,即并发事务相继对相同的记录做出改动。
在这种情况下会发生 脏写
的问题,任何一种隔离级别都不允许这种问题的发生。所以在多个未提交事务相继对一条记录做改动时,需要让它们 排队执行
,这个排队的过程其实是通过 锁
来实现的。这个所谓的锁其实是一个 内存中的结构
,在事务执行前本来是没有锁的,也就是说一开始是没有 锁结构
和记录进行关联的,如图所示:
当一个事务想对这条记录做改动时,首先会看看内存中有没有与这条记录关联的 锁结构
,当没有的时候就会在内存中生成一个 锁结构
与之关联。
比如,事务 T1 要对这条记录做改动,就需要生成一个 锁结构与之关联:
其实在锁结构
里有很多信息,不过为了简化理解,我们现在只把两个比较重要的属性拿了出来:
trx信息
:代表这个锁结构是哪个事务生成的。is_waiting
:代表当前事务是否在等待。 如图所示,当事务T1
改动了这条记录后,就生成了一个锁结构
与该记录关联,因为之前没有别的事务为这条记录加锁,所以is_waiting
属性就是false
,我们把这个场景就称之为获取锁成功,或者加锁成功,然后就可以继续执行操作了。
在事务T1
提交之前,另一个事务T2
也想对该记录做改动,那么先去看看有没有锁结构
与这条记录关联,发现有一个锁结构
与之关联后,然后也生成了一个锁结构
与这条记录关联,不过锁结构
的is_waiting
属性值为true
,表示当前事务需要等待,我们把这个场景就称之为获取锁失败,或者加锁失败,或者没有成功的获取到锁,画个图表示就是这样:
在事务T1
提交之后,就会把该事务生成的锁结构
释放掉,然后看看还有没有别的事务在等待获取锁,发现了事务T2
还在等待获取锁,所以把事务T2
对应的锁结构的is_waiting
属性设置为false
,然后把该事务对应的线程唤醒,让它继续执行,此时事务T2
就算获取到锁了。效果图就是这样:
小结几种说法:
- 不加锁
- 意思就是不需要在内存中生成对应的
锁结构
,可以直接执行操作。
- 意思就是不需要在内存中生成对应的
- 获取锁成功,或者加锁成功
- 意思就是在内存中生成了对应的
锁结构
,而且锁结构的is_waiting
属性为false
,也就是事务可以继续执行操作。
- 意思就是在内存中生成了对应的
- 获取锁失败,或者加锁失败,或者没有获取到锁
- 意思就是在内存中生成了对应的
锁结构
,不过锁结构的is_waiting
属性为true
,也就是事务需要等待,不可以继续执行操作。
- 意思就是在内存中生成了对应的
2.3 读-写或写-读情况
读-写
或写-读
,即一个事务进行读取操作,另一个进行改动操作。这种情况下可能发生 脏读
、 不可重复读 、 幻读
的问题。
SQL标准
规定不同隔离级别下可能发生的问题不一样:
- 在
READ UNCOMMITTED
隔离级别下,脏读
、不可重复读
、幻读
都可能发生。 - 在
READ COMMITTED
隔离级别下,不可重复读
、幻读
可能发生,脏读
不可以发生。 - 在
REPEATABLE READ
隔离级别下,幻读
可能发生,脏读
和不可重复读
不可以发生。 - 在
SERIALIZABLE
隔离级别下,上述问题都不可以发生。
各个数据库厂商对 SQL标准 的支持都可能不一样。比如MySQL在 REPEATABLE READ
隔离级别上就已经解决了 幻读
问题。
2.4 并发问题的解决方案
怎么解决 脏读 、 不可重复读 、 幻读
这些问题呢?其实有两种可选的解决方案:
- 方案一:读操作利用多版本并发控制(
MVCC
),写操作进行加锁
。
所谓的MVCC
我们在下一章进行详细的描述,就是通过生成一个ReadView
,然后通过ReadView
找到符合条件的记录版本(历史版本是由undo日志
构建的),其实就像是在生成ReadView
的那个时刻做了一次时间静止(就像用相机拍了一个快照),查询语句只能读到在生成ReadView
之前已提交事务所做的更改,在生成ReadView
之前未提交的事务或者之后才开启的事务所做的更改是看不到的。而写操作肯定针对的是最新版本的记录,读记录的历史版本和改动记录的最新版本本身并不冲突,也就是采用MVCC
时,读-写
操作并不冲突。
普通的SELECT语句在READ COMMITTED和REPEATABLE READ隔离级别下会使用到MVCC读取记录。
- 在
READ COMMITTED
隔离级别下,一个事务在执行过程中每次执行SELECT操作时都会生成一个ReadView
,ReadView的存在本身就保证了事务不可以读取到未提交的事务所做的更改
,也就是避免了脏读现象;- 在
REPEATABLE READ
隔离级别下,一个事务在执行过程中只有第一次执行SELECT操作
才会生成一个ReadView,之后的SELECT操作都复用
这个ReadView,这样也就避免了不可重复读和幻读的问题。
- 方案二:读、写操作都采用
加锁
的方式
如果我们的一些业务场景不允许读取记录的旧版本,而是每次都必须去读取记录的最新版本,比方在银行存款的事务中,你需要先把账户的余额读出来,然后将其加上本次存款的数额,最后再写到数据库中。在将账户余额读取出来后,就不想让别的事务再访问该余额,直到本次存款事务执行完成,其他事务才可以访问账户的余额。这样在读取记录的时候也就需要对其进行加锁
操作,这样也就意味着读
操作和写
操作也像写-写
操作那样排队执行。
脏读
的产生是因为当前事务读取了另一个未提交事务写的一条记录,如果另一个事务在写记录的时候就给这条记录加锁,那么当前事务就无法继续读取该记录了,所以也就不会有脏读问题的产生了。
不可重复读
的产生是因为当前事务先读取一条记录,另外一个事务对该记录做了改动之后并提交之后,当前事务再次读取时会获得不同的值,如果在当前事务读取记录时就给该记录加锁,那么另一个事务就无法修改该记录,自然也不会发生不可重复读了。
幻读
问题的产生是因为当前事务读取了一个范围的记录,然后另外的事务向该范围内插入了新记录,当前事务再次读取该范围的记录时发现了新插入的新记录。采用加锁的方式解决幻读问题就有一些麻烦,因为当前事务在第一次读取记录时幻影记录并不存在,所以读取的时候加锁就有点尴尬(因为你并不知道给谁加锁)。
- 小结对比发现:
- 采用
MVCC
方式的话,读-与
操作彼此并不冲突,性能更高
。 - 采用
加锁
方式的话,读-写
操作彼此需要排队执行
,影响性能。 一般情况下我们当然愿意采用MVCC
来解决读-写操作并发执行
的问题,但是业务在某些特殊情况下,要求必须采用加锁
的方式执行。下面就讲解下MySQL中不同类别的锁。
- 采用
3. 锁的不同角度分类
锁的分类图,如下:
3.1 从数据操作的类型划分:读锁、写锁
对于数据库中并发事务的读-读
情况并不会引起什么问题。对于写-写、读-写或写-读
这些情况可能会引起一些问题,需要使用MVCC
或者加锁
的方式来解决它们。在使用加锁
的方式解决问题时,由于既要允许读-读情况不受影响,又要使写-写、读-写或写-读
情况中的操作相互阻塞,所以MySQL实现一个由两种类型的锁组成的锁系统来解决。这两种类型的锁通常被称为共享锁(Shared Lock,S Lock)和排他锁(Exclusive Lock,X Lock)
也叫读锁(read lock)和写锁(write lock)。
- 读锁:也称为
共享锁、英文用S表示
。针对同一份数据,多个事务的读操作可以同时进行而不会互相影响
,相互不阻塞的。 - 写锁:也称为
排他锁、英文用X表示
。当前写操作没有完成前,它会阻断其他写锁和读锁。这样 就能确保在给定的时间里,只有一个事务能执行写入,并防止其他用户读取正在写入的同一资源。
需要注意的是对于 InnoDB 引擎来说,读锁和写锁可以加在表上,也可以加在行上。
举例(行级读写锁):如果一个事务T1已经获得了某个行的读锁,那么此时另外的一个事务T2是可以去获得 这个行的读锁的,因为读取操作并没有改变行的数据;但是,如果某个事务T3想获得行的写锁,则它必须 等待事务T1、T2释放掉行 上的读锁才行。
总结:这里的兼容是指对同一张表或记录的锁的兼容性情况。
X锁 | S锁 | |
---|---|---|
X锁 | 不兼容 | 不兼容 |
S锁 | 不兼容 | 兼容 |
3.1.1 锁定读
采用加锁
方式解决脏读
、不可重复读
、幻读
这些问题时,读取一条记录时需要获取一下该记录的S锁
,其实这是不严谨的,有时候想在读取记录时就获取记录的X锁
,来禁止别的事务读写该记录,为此设计MySQL
的大佬提出了两种比较特殊的SELECT
语句格式:
-
对读取的记录加
S锁
:SELECT ... LOCK IN SHARE MODE;
也就是在普通的
SELECT
语句后边加LOCK IN SHARE MODE
,如果当前事务执行了该语句,那么它会为读取到的记录加S锁
,这样允许别的事务继续获取这些记录的S锁
(比方说别的事务也使用SELECT ... LOCK IN SHARE MODE
语句来读取这些记录),但是不能获取这些记录的X锁
(比方说使用SELECT ... FOR UPDATE
语句来读取这些记录,或者直接修改这些记录)。如果别的事务想要获取这些记录的X锁
,那么它们会阻塞,直到当前事务提交之后将这些记录上的S锁
释放掉。 -
对读取的记录加
X锁
:SELECT ... FOR UPDATE;
也就是在普通的
SELECT
语句后边加FOR UPDATE
,如果当前事务执行了该语句,那么它会为读取到的记录加X锁
,这样既不允许别的事务获取这些记录的S锁
(比方说别的事务使用SELECT ... LOCK IN SHARE MODE
语句来读取这些记录),也不允许获取这些记录的X锁
(比方也说使用SELECT ... FOR UPDATE
语句来读取这些记录,或者直接修改这些记录)。如果别的事务想要获取这些记录的S锁
或者X锁
,那么它们会阻塞,直到当前事务提交之后将这些记录上的X锁
释放掉。
3.1.2 写操作
平常所用到的写操作
无非是DELETE
、UPDATE
、INSERT
这三种:
-
DELETE
:对一条记录做
DELETE
操作的过程其实是先在B+
树中定位到这条记录的位置,然后获取一下这条记录的X锁
,然后再执行delete mark
操作。我们也可以把这个定位待删除记录在B+
树中位置的过程看成是一个获取X锁
的锁定读
。 -
UPDATE
:在对一条记录做UPDATE
操作时分为三种情况:-
如果未修改该记录的键值并且被更新的列占用的存储空间在修改前后未发生变化,则先在
B+
树中定位到这条记录的位置,然后再获取一下记录的X锁
,最后在原记录的位置进行修改操作。其实我们也可以把这个定位待修改记录在B+
树中位置的过程看成是一个获取X锁
的锁定读
。 -
如果未修改该记录的键值并且至少有一个被更新的列占用的存储空间在修改前后发生变化,则先在
B+
树中定位到这条记录的位置,然后获取一下记录的X锁
,将该记录彻底删除掉(就是把记录彻底移入垃圾链表),最后再插入一条新记录。这个定位待修改记录在B+
树中位置的过程看成是一个获取X锁
的锁定读
,新插入的记录由INSERT
操作提供的隐式锁
进行保护。 -
如果修改了该记录的键值,则相当于在原记录上做
DELETE
操作之后再来一次INSERT
操作,加锁操作就需要按照DELETE
和INSERT
的规则进行了。
-
-
INSERT
:- 一般情况下,新插入一条记录的操作并不加锁,设计
InnoDB
的大佬通过一种称之为隐式锁
的东东来保护这条新插入的记录在本事务提交前不被别的事务访问。
- 一般情况下,新插入一条记录的操作并不加锁,设计
MySQL8.0新特性:
在5.7及之前的版本,SELECT...FOR UPDATE,如果获取不到锁,会一直等待,直到
innodb_lock_wait_timeout
超时。在8.0版本中,SELECT...FOR UPDATE,SELECT...FOR SHARE
添加NOWAIT、SKIP LOCKED语法,跳过锁等待,或者跳过锁定。
- 通过添加NOWAIT、SKIP LOCKED语法,能够立即返回。如果查询的行已经加锁:
- 那么NOWAT会立即报错返回
- 而SKIP LOCKED也会立即返回,只是返回的结果中不包含被锁定的行。
3.2 从数据操作的粒度划分:表级锁、页级锁、行锁
为了尽可能提高数据库的并发度,每次锁定的数据范围越小越好,理论上每次只锁定当前操作的数据的方案会得到最大的并发度,但是管理锁是很耗资源
的事情(涉及获取、检查、释放锁等动作)。因此数据库系统需要在高并发响应
和系统性能
两方面进行平衡,这样就产生了“锁粒度
(Lock granularity)”的概念。
对一条记录加锁影响的也只是这条记录而已,我们就说这个锁的粒度比较细;其实一个事务也可以在表级别进行加锁,自然就被称之为表级锁或者表锁
,对一个表加锁影响整个表中的记录,我们就说这个锁的粒度比较粗。锁的粒度主要分为表级锁、页级锁和行锁。
3.2.1 表锁(Table Lock)
该锁会锁定整张表,它是MySQL中最基本的锁策略,并不依赖于存储引擎
(不管你是MySQL的什么存储引擎,对于表锁的策略都是一样的),并且表锁是开销最小
的策略(因为粒度比较大)。由于表级锁一次会将整个表锁定,所以可以很好的避免死锁
问题。当然,锁的粒度大所带来最大的负面影响就是出现锁资源争用的概率也会最高,导致并发率大打折扣
。
3.2.1.1 表级别的S锁、X锁
在对某个表执行SELECT、INSERT、DELETE、UPDATE语句时,InnoDB存储引擎是不会为这个表添加表级别的 S锁或者X锁
的。在对某个表执行一些诸如 ALTER TABLE 、 DROP TABLE
这类的 DDL 语句时,其他事务对这个表并发执行诸如SELECT、INSERT、DELETE、UPDATE的语句会发生阻塞。同理,某个事务中对某个表执行SELECT、INSERT、DELETE、UPDATE语句时,在其他会话中对这个表执行 DDL 语句也会发生阻塞。这个过程其实是通过在 server层
使用一种称之为 元数据锁
(英文名:Metadata Locks
,简称 MDL )结构来实现的。
一般情况下,不会使用InnoDB存储引擎提供的表级别的 S锁
和 X锁
。只会在一些特殊情况下,比方说 崩溃恢复
过程中用到。比如,在系统变量 autocommit=0,innodb_table_locks = 1 时, 手动 获取InnoDB存储引擎提供的表t 的 S锁或者 X锁
可以这么写:
LOCK TABLES t READ
:InnoDB存储引擎会对表 t 加表级别的 S锁 。LOCK TABLES t WRITE
:InnoDB存储引擎会对表 t 加表级别的 X锁 。 不过尽量避免在使用InnoDB存储引擎的表上使用LOCK TABLES 这样的手动锁表语句,它们并不会提供什么额外的保护,只是会降低并发能力而已。InnoDB的厉害之处还是实现了更细粒度的行锁
,关于InnoDB表级别的S锁
和X锁
大家了解一下就可以了。
MySQL的表级锁有两种模式:(以MyISAM表进行操作的演示)
- 表共享读锁(Table Read Lock)
- 表独占写锁(Table Write Lock)
锁类型 | 自己可读 | 自己可写 | 自己可操作其他表 | 他人可读 | 他人可写 |
---|---|---|---|---|---|
读锁 | 是 | 否 | 否 | 是 | 否,等 |
写锁 | 是 | 是 | 否 | 否,等 | 否,等 |
总结:
MyISAM在执行查询语句(SELECT)前,会给涉及的所有表加读锁
,在执行增删改操作前,会给涉及的表加写锁
。InnoDB存储引擎
是不会为这个表添加表级别的读锁或者写锁
的。
3.2.1.2 意向锁 (intention lock)
InnoDB支持多粒度锁(multiple granularity locking)
,它允许行级锁与表级锁共存,而意向 锁就是其中的一种表锁
。
- 意向锁的存在是为了协调行锁和表锁的关系,支持多粒度(表锁与行锁)的锁并存。
- 意向锁是一种不与行级锁冲突表级锁,这一点非常重要。
- 表明“某个事务正在某些行持有了锁或该事务准备去持有锁”
意向锁分为两种:
- 意向共享锁(intention shared lock, IS):事务有意向对表中的某些行加共享锁(S锁)
- 事务要获取某些行的S锁,必须先获得表的IS锁。 SELECT column FROM table ... LOCK IN SHARE MODE;
- 意向排他锁(intention exclusive lock, IX):事务有意向对表中的某些行加排他锁(X锁)
- 事务要获取某些行的X锁,必须先获得表的IX锁。 SELECT column FROM table ... FOR UPDATE;
即:意向锁是由存储引擎自己维护的,用户无法手动操作意向锁,在为数据行加共享/排他锁之前, InnoDB会先获取该数据行加数据表的对应意向锁。
1. 意向锁要解决的问题
现在有两个事务,分别是T1和T2,其中T2试图在该表级别上应用共享或排它锁,如果没有意向锁存在,那么T2就需要去检查各个页或行是否存在锁:如果存在意向锁,那么此时就会受到由T1控制的表级别意向锁的阻塞
。T2在锁定该表前不必检查各个页或行锁,而只需检查表上的意向锁。简单来说就是给更大一级别的空间示意里面是否已经上过锁。
在数据表的场景中,如果我们给某一行数据加上了排它锁,数据库会自动给更大一级的空间,比如数据页或数据表加上意向锁,告诉其他人这个数据页或数据表已经有人上过排它锁了
,这样当其他人想要获取数据表排它锁的时候,只需要了解是否有人已经获取了这个数据表的意向排他锁即可。
- 如果事务想要获得数据表中某些记录的共享锁,就需要在数据表上
添加意向共享锁
。 - 如果事务想要获得数据表中某些记录的排他锁,就需要在数据表上
添加意向排他锁
。
这时,意向锁会告诉其他事务已经有人锁定了表中的某些记录。
举例:创建表teacher,插入6条数据,事务的隔离级别默认为Repeatable-Read
,如下所示。
CREATE TABLE teacher(
'id' int NOT NULL,
'name' varchar(255) NOT NULL,
PRIMARY KEY ('id')
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
INSERT INTO teacher VALUES
('1','zhangsan'),
('2',lis1),
('3','wangwu'),
('4','zhaoliu'),
('5','zhaoliu'),
('6','zhuqi');
mysql>SELECT @@transaction_isolation;
假设事务A获取了某一行的排他锁
,并未提交,语句如下所示。
begin;
SELECT FROM teacher WHERE id = 6 FOR UPDATE;
事务B想要获取teacher表的表读锁
,语句如下。
begin;
LOCK TABLES teacher READ;
因为共享锁与排他锁互斥,所以事务B在试图对teacher表加共享锁的时候,必须保证两个条件。
- 当前没有其他事务持有teacher表的排他锁
- 当前没有其他事务持有teacher表中任意一行的排他锁。
为了检测是否满足第二个条件,事务B必须在确保teacher表不存在任何排他锁的前提下,去检测表中的每一行是否存在排他锁。很明显这是一个效率很差的做法,但是有了意向锁之后,情况就不一样了。
意向锁是怎么解决这个问题的呢?首先,我们需要知道意向锁之间的兼容互斥性,如下所示。
意向共享锁(IS) | 意向排他锁(IX) | |
---|---|---|
意向共享锁(IS) | 兼容 | 兼容 |
意向排他锁(IX) | 兼容 | 兼容 |
即意向锁之间是互相兼容的,虽然意向锁和自家兄弟互相兼容,但是它会与普通的排他/共享锁互斥
。
意向共享锁(IS) | 意向排他锁(IX) | |
---|---|---|
共享锁(S) | 兼容 | 互斥 |
排他锁(X) | 互斥 | 互斥 |
注意这里的排他/共享锁指的都是表锁,意向锁不会与行级的共享/排他锁互斥
。回到刚才teacher表的例子。
事务A获取了某一行的排他锁,并未提交:
BEGIN;
SELECT FROM teacher WHERE id = 6 FOR UPDATE;
此时teacher表存在两把锁:teacher表上的意向排他锁与id为6的数据行上的排他锁。事务B想要获取teacher表的共享锁。
BEGIN;
LOCK TABLES teacher READ;
此时事务B检测事务A持有teacher表的意向排他锁,就可以得知事务A必然特有该表中某些数据行的排他锁, 那么事务B对teacher表的加锁请求就会被排斥(阻塞),而无需去检测表中的每一行数据是否存在排他锁。
2. 意向锁的并发性
意向锁不会与行级的共享/排他锁互斥!
正因为如此,意向锁并不会影响到多个事务对不同数据行加排
他锁时的并发性。(不然我们直接用普通的表锁就行了)
我们扩展一下上面 teacher表的例子来概括一下意向锁的作用(一条数据从被锁定到被释放的过程中,可能存在多种不同锁,但是这里我们只着重表现意向锁)。
事务A先获取了某一行的排他锁,并未提交:
BEGIN;
SELECT FROM teacher WHERE id = 6 FOR UPDATE;
事务A获取了teacher表上的意向排他锁,事务A获取了id为6的数据行上的排他锁。之后事务B想要获取teacher表的共享锁。
BEGIN;
LOCK TABLES teacher READ;
事务B检测到事务A持有teacher表的意向排他锁。事务B对teacher表的加锁请求被阻塞(排斥)。最后事务C也想获取teacher表中某一行的排他锁。
BEGIN;
SELECT FROM teacher WHERE id = 5 FOR UPDATE;
事务C申请teacher表的意向排他锁。事务C检测到事务A持有teacher表的意向排他锁。因为意向锁之间并不互斥,所以事务C获取到了teacher表的意向排他锁。因为id为5的数据行上不存在任何排他锁,最终事务C成功获取到了该数据行上的排他锁。
从上面的案例可以得到如下结论:
- InnoDB 支持
多粒度锁
,特定场景下,行级锁可以与表级锁共存
。 意向锁之间互不排斥
,但除了 IS 与 S 兼容外, 意向锁会与 共享锁 / 排他锁 互斥 。IX,IS是表级锁
,不会和行级的X,S锁发生冲突
。只会和表级的X,S发生冲突。- 意向锁在保证
并发性
的前提下,实现了行锁和表锁共存
且满足事务隔离性
的要求。
3.2.1.3 自增锁(AUTO-INC锁)
在使用MySQL过程中,我们可以为表的某个列添加 AUTO_INCREMENT
属性。举例:
CREATE TABLE `teacher` (
`id` int NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
由于这个表的id字段声明了AUTO_INCREMENT
,意味着在书写插入语句时不需要为其赋值,SQL语句修改如下所示。
INSERT INTO `teacher` (name) VALUES ('zhangsan'), ('lisi');
上边的插入语句并没有为id列显式赋值,所以系统会自动为它赋上递增的值,结果如下所示。
mysql> select * from teacher;
+----+----------+
| id | name |
+----+----------+
| 1 | zhangsan |
| 2 | lisi |
+----+----------+
2 rows in set (0.00 sec)
现在我们看到的上面插入数据只是一种简单的插入模式,所有插入数据的方式总共分为三类,分别是:
“ Simple inserts
”,“ Bulk inserts
”和“ Mixed-mode inserts
”。
-
"Simple inserts"(简单插入)
可以预先确定要插入的行数
(当语句被初始处理时)的语句。包括没有嵌套子查询的单行和多行INSERT... VALUES 和 REPLACE
语句。比如我们上面举的例子就属于该类插入,已经确定要插入的行数。 -
"Bulk inserts"(批量插入)
事先不知道要插入的行数(和所需自动递增值的数量)的语句。比如INSERT ... SELECT , REPLACE ... SELECT和LOAD DATA语句
,但不包括纯INSERT。InnoDB在每处理一行,为AUTO_INCREMENT 分配一个新值。 -
"Mixed-mode inserts"(混合模式插入)
这些是"Simple inserts"语句但是指定部分新行的自动递增值。例如INSERT INTO teacher (id, name) VALUES (1, 'a' ), (NULL, 'b' ), (5, 'c'), (NULL, d )
;只是指定了部分 id 的值。另一种类型的“混合模式插入”是 INSERT . . . ON DUPLICATE KEY UPDATE。
对于上面数据插入的案例,MySQL中采用了自增锁
的方式来实现,AUTO-INC锁是当向使用含有AUTO_INCREMENT列的表中插入数据时需要获取的一种特殊的表级锁
,在执行插入语句时就在表级别加一个AUTO-INC锁,然后为每条待插入记录的AUTO_INCREMENT修饰的列分配递增的值,在该语句执行结束后,再把AUTO-INC锁释放掉。一个事务在持有AUTO-INC锁的过程中,其他事务的插入语句都要被阻塞
,可以保证一个语句中分配的递增值是连续的。也正因为此,其并发性显然并不高,当我们向一个有AUTO_INCREMENT:关键字的主键插入值的时候,每条语句都要对这个表锁进行竟争
,这样的并发潜力其实是很低下的,所以InnoDB通过innodb_autoinc_lock_mode
的不同取值来提供不同的锁定机制,来显著提高SQL语句的可伸缩性和性能。
innodb_autoinc_lock_mode
有三种取值,分别对应与不同锁定模式:
-
innodb_autoinc_lock_mode = 0
("传统"锁定模式)- 在此锁定模式下,所有类型的insert语句都会获得一个特殊的表级AUTO-INC锁,用于插入具有 AUTO_INCREMENT的表。这种模式其实就如我们上面的例子,即每当执行insert的时候,都会得到一个
表级锁
(AUTO-INC锁),使得语句中生成的auto_increment为自增,且在binlog中重放的时候,可以保证 master与slave中数据的auto_increment是相同的。因为是表级锁,当在同一时间多个事务中执行insert的 时候,对于AUTO-INC锁的争夺会限制并发
能力。
- 在此锁定模式下,所有类型的insert语句都会获得一个特殊的表级AUTO-INC锁,用于插入具有 AUTO_INCREMENT的表。这种模式其实就如我们上面的例子,即每当执行insert的时候,都会得到一个
-
innodb_autoinc_lock_mode = 1
("连续"锁定模式)- 在MySQL 8.0之前,连续锁定模式是默认的。
- 在这个模式下,“bulk inserts”仍然使用AUTO-INC表级锁,并保持到语句结束。这适用于所有INSERT ... SELECT, REPLACE ... SELECT和LOAD DATA语句。同一时刻只有一个语句可以持有AUTO-INC锁。
- 对于“Simple inserts”(要插入的行数事先已知),则通过在
mutex (轻量锁)
的控制下获得所需数量的 自动递增值来避免表级AUTO-INC锁,它只在分配过程的持续时间内保持,而不是直到语句完成。不使用 表级AUTO-INC锁,除非AUTO-INC锁由另一个事务保持。如果另T事务保持AUTO-INC锁,{^“Simple inserts"等待AUTO-INC锁,如同它是一个"bulk inserts"。
-
innodb_autoir)c_lock_mode = 2
("交错"锁定模式)-
从MySQL 8.0开始,交错锁模式是默认设置。
-
在此锁定模式下,自动递增值保语在所有并发执行的所有类型的insert语句中是唯 且单调递增的。但 是,由于多个语句可以同时生成数字(即,跨语句交叉编号),为任何给定语句
插入的行生成的值可能 不是连续的
。 -
如果执行的语句是“simple inserts'”,其中要插入的行数已提前知道,除了“Mixed-.mode inserts"之外,为单个语句生成的数字不会有间隙。然而,当执行“bulk inserts"时,在由任何给定语句分配的自动递增值中可能存在间隙。
-
3.2.14 元数据锁(MDL锁)
MySQL5.5引入了meta data lock
,简称MDL锁
,属于表锁范畴。
MDL 的作用是,保证读写的正确性。比如,如果一个查询正在遍历一个表中的数据,而执行期间另一个线程对这个 表结构做变更
,增加了一列,那么查询线程拿到的结果跟表结构对不上,肯定是不行的。
因此,当对一个表做增删改查操作的时候,加 MDL读锁;当要对表做结构变更操作的时候,加 MDL 写锁
。
读锁之间不互斥,因此你可以有多个线程同时对一张表增删改查。读写锁之间、写锁之间是互斥的,用来保证变更表结构操作的安全性,解决了DML和DDL操作之间的一致性问题。不需要显式使用
,在访问一个表的时候会被自动加上。
举例:元数据锁的使用场景模拟
会话A:查询数据
mysql>begin;
Query OK,0 rows affected (0.00 sec)
mysql>select count(1)from teacher;
+----------+
| count(1) |
| 2 |
+----------+
1 row in set (7.46 sec)
会话B:修改表结构,增加新列
mysql>begin;
Query OK,0 rows affected (0.00 sec)
mysql>alter table teacher add age int not null;
会话C:查看当前MySQL的进程
mysql>show processlist;
通过会话c可以看出会话B被阻塞,这是由于会话A拿到了teacher表的元数据读锁,会话B想申请teacher表的元数据写锁,由于读写锁互斥,会话B需要等待会话A释放元数据锁才能执行。
元数据锁可能带来的问题
我们可以看到session A会对表teacher)加一个MDL读锁,之后session B要加MDL写锁会被blocked,因为session A
的MDL读锁还没有释放,而session C要在表teacher上新申请MDL读锁的请求也会被session B阻塞。前面我们
说了,所有对表的增删改查操作都需要先申请MDL读锁,就都被阻塞,等于这个表现在完全不可读写了
。
3.2.2 InnoDB中的行锁
行锁(Row Lock)也称为记录锁,顾名思义,就是锁住某一行(某条记录ROW)。需要的注意的是,MySQL服务
器层并没有实现行锁机制,行级锁只在存储引擎层实现
。
优点
:锁定力度小,发生锁冲突概率低
,可以实现的并发度高
。
缺点
:对于锁的开销比较大
,加锁会比较慢,容易出现死锁情况
。
InnoDB与MyISAM的最大不同有两点:一是支持事务(TRANSACTION);二是采用了行级锁。
首先我们创建表如下:
CREATE TABLE student(
id INT,
name VARCHAR(20),
class varchar(10),
PRIMARY KEY (id)I
Engine=InnoDB CHARSET=utf8;
向这个表里插入几条记录:
INSERT INTO student VALUES
(1,张三,一班),
(3,李四,一班),
(8,王五,三班),
(15,‘赵六”,‘三班),
(28,线七‘,‘三班);
mysql>SELECT FROM student;
student表中的聚簇索引的简图如下所示。 这里把B+树的索引结构做了一个超级简化,只把索引中的记录给拿了出来,下面看看都有哪些常用的行锁类型。
3.2.1.1 记录锁(Record Locks)
记录锁也就是仅仅把一条记录锁上,官方类型为LOCK_REC_NOT_GAP
,比如我们把id值为8 的那条记录加一个记录锁的示意图如下,仅仅是锁住了id为8的记录,对周围的数据没有影响。
举例如下:
记录锁是有S锁和X锁之分的,称之为 S型记录锁 和 X型记录锁 。
- 当一个事务获取了一条记录的S型记录锁后,其他事务也可以继续获取该记录的S型记录锁,但不可以继续获取X型记录锁;
- 当一个事务获取了一条记录的X型记录锁后,其他事务既不可以继续获取该记录的S型记录锁,也不可以继续获取X型记录锁。
3.2.1.2 间隙锁(Gap Locks)
MySQL 在 REPEATABLE READ
隔离级别下是可以解决幻读问题的,解决方案有两种,可以使用 MVCC
方案解决,也可以采用 加锁
方案解决。但是在使用加锁方案解决时有个大问题,就是事务在第一次执行读取操作时,那些幻影记录尚不存在,我们无法给这些 幻影记录
加上 记录锁
。InnoDB提出了一种称之为Gap Locks 的锁,官方的类型名称为: LOCK_GAP
,我们可以简称为 gap锁
。
比如,把id值为8的那条记录加一个gap锁的示意图如下。
图中id值为8的记录加了gap锁,意味着 不允许别的事务在id值为8的记录前边的间隙插入新记录
,其实就是id列的值(3, 8)这个区间的新记录是不允许立即插入的。比如,有另外一个事务再想插入一条id值为4的新记录,它定位到该条新记录的下一条记录的id值为8,而这条记录上又有一个gap锁,所以就会阻塞插入操作,直到拥有这个gap锁的事务提交了之后,id列的值在区间(3, 8)中的新记录才可以被插入。
gap锁的提出仅仅是为了防止插入幻影记录而提出的
。虽然有共享gap锁
和独占gap锁
这样的说法,但是它们起到的作用是相同的。而目如果对一条记录加了gap锁(不论是共享gap锁还是独占gap锁),并不会限制其他事务对这条记录加记录锁或者继续加gap锁。
Session1 | Session2 |
---|---|
select * from student where id = 5 lock in share mode; | |
select * from student where id =5 for update |
这里session2并不会被堵住。因为表里并没有id=5这个记录,因此session1加的是间隙锁(3,8)。而session2也是在这个间隙加的间隙锁。它们有共同的目标,即:保护这个间隙,不允许插入值。但,它们之间是不冲突的。
注意,给一条记录加了gap锁
只是不允许
其他事务往这条记录前边的间隙插人新记录
,那对于最后一条记录之后的间隙,也就是student表中id值为20的记录之后的间隙该咋办呢?也就是说给哪条记录加gap锁才能阻止其他事务插入id值在(28,+∞)这个区间的新记录呢?这时候我们在讲数据页时介绍的两条伪记录派上用场了:
Infimum
记录,表示该页面中最小的记录。Supremum
记录,表示该页面中最大的记录。
为了实现阻止其他事务插入id值在(20,+oo)这个区间的新记录,我们可以给索引中的最后一条记录,也就是id值为20的那条记录所在页面的Supremum记录加上一个gap锁,如图所示。
mysql>select from student where id >20 lock in share mode;
Empty set (0.01 sec)
这样就可以阻止其他事务插入id值在(20,+∞)这个区间的新记录。 间隙锁的引入,可能会导致同样的语句锁住更大的范围,这其实是影响了并发度的。下面的例子会产生死锁:
- session1执行select..for update语句,由于id=5这一行并不存在,因此会加上间隙锁(3,8);
- session2执行select..for update语句,同样会加上间隙锁(3,8),间隙锁之间不会冲突,因此这个语句可以执行成功;
- session2试图插入一行(5,'宋红康,二班),被session1的间隙锁挡住了,只好进入等待;
- session1试图插入一行(5,宋红康,二班),被session2的间隙锁挡住了。至此,两个session进入互相等待状态,形成
死锁
。当然,InnoDB的死锁检测马上就发现了这对死锁关系,让session1的insert语句报错返回。
3.2.1.3 临键锁(Next-Key Locks)
有时候我们既想 锁住某条记录
,又想 阻止
其他事务在该记录前边的 间隙插入新记录
,所以InnoDB就提出了一种称之为 Next-Key Locks
的锁,官方的类型名称为: LOCK_ORDINARY
,我们也可以简称为next-key锁
。Next-Key Locks
是在存储引擎 innodb 、事务级别在 可重复读
的情况下使用的数据库锁,innodb默认的锁就是Next-Key locks
。比如,我们把id值为8的那条记录加一个next-key锁的示意图如下:
next-key锁的本质就是一个记录锁
和一个gap锁
的合体,它既能保护该条记录,又能阻止别的事务将新记录插入被保护记录前边的间隙
。
3.2.1.4 插入意向锁(Insert Intention Locks)
我们说一个事务在 插入
一条记录时需要判断一下插入位置是不是被别的事务加了 gap锁
( next-key锁也包含 gap锁 ),如果有的话,插入操作需要等待,直到拥有 gap锁
的那个事务提交。但是InnoDB规定事务在等待的时候也需要在内存中生成一个锁结构,表明有事务想在某个 间隙
中 插入
新记录,但是现在在等待。InnoDB就把这种类型的锁命名为 Insert Intention Locks
,官方的类型名称为:
LOCK_INSERT_INTENTION
,我们称为 插入意向锁
。插入意向锁是一种 Gap锁
,不是意向锁,在insert操作时产生。
插入意向锁是在插入一条记录行前,由 INSERT 操作产生的一种间隙锁
。该锁用以表示插入意向,当多个事务在同一区间(gap)插入位置不同的多条数据时,事务之间不需要互相等待。假设存在两条值分别为4和7的记录,两个不同的事务分别试图插入值为5和6的两条记录,每个事务在获取插入行上独占的(排他)锁前,都会
获取(4,7)之间的间隙锁,但是因为数据行之间并不冲突
,所以两个事务之间并不会产生冲突(阻塞等待)。总结来说,插入意向锁的特性可以分成两部分:
- 插入意向锁是一种
特殊的间隙锁
一一间隙锁可以锁定开区间内的部分记录。 - 插入意向锁之间
互不排斥
,所以即使多个事务在同一区间插入多条记录,只要记录本身(主键、唯一索引)不冲突,那么事务之间就不会出现冲突等待。
注意,虽然插入意向锁中含有意向锁三个字,但是它并不属于意向锁而属于间隙锁,因为意向锁是表锁而插入意向锁是行锁
。
比如,把id值为8的那条记录加一个插入意向锁的示意图如下:
比如,现在T1为id值为8的记录加了一个gap锁,然后T2和T3分别想向student表中插入id值分别为4、5的两条记录,所以现在为id值为8的记录加的锁的示意图就如下所示:
从图中可以看到,由于T1持有gap锁,所以T2和T3需要生成一个插入意向锁的锁结构并且处于等待状态。当T1提
交后会把它获取到的锁都释放掉,这样T2和T3就能获取到对应的插入意向锁了(本质上就是把插入意向锁对应锁
结构的is_waiting属性改为false),T2和T3之间也并不会相互阻塞,它们可以同时获取到id值为8的插入意向锁,
然后执行插入操作。事实上插入意向锁并不会阻止别的事务继续获取该记录上任何类型的锁
。
3.2.3 页锁
页锁就是在 页的粒度
上进行锁定,锁定的数据资源比行锁要多,因为一个页中可以有多个行记录。
当我们使用页锁的时候,会出现数据浪费的现象,但这样的浪费最多也就是一个页上的数据行。页锁的开销介于表锁和行锁之间,会出现死锁。锁定粒度介于表锁和行锁之间,并发度一般
。
每个层级的锁数量是有限制的,因为锁会占用内存空间, 锁空间的大小是有限的 。当某个层级的锁数量超过了这个层级的阈值时,就会进行锁升级 。锁升级就是用更大粒度的锁替代多个更小粒度的锁,比如InnoDB 中行锁升级为表锁,这样做的好处是占用的锁空间降低了,但同时数据的并发度也下降了。
3.3 从对待锁的态度划分:乐观锁、悲观锁
从对待锁的态度来看锁的话,可以将锁分成乐观锁和悲观锁,从名字中也可以看出这两种锁是两种看待数据并发的思维方式
。需要注意的是,乐观锁和悲观锁并不是锁,而是锁的 设计思想
。
3.3.1 悲观锁(Pessimistic Locking)
悲观锁是一种思想,顾名思义,就是很悲观,对数据被其他事务的修改持保守态度,会通过数据库自身的锁机制来实现,从而保证数据操作的排它性。
悲观锁总是假设最坏的情况,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会 阻塞 直到它拿到锁(共享资源每次只给一个线程使用,其它线程阻塞,用完后再把资源转让给其它线程
)。比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁,当其他线程想要访问数据时,都需要阻塞挂起。Java中 synchronized 和 ReentrantLock
等独占锁就是悲观锁思想的实现。
秒杀案例1: 商品秒杀过程中,库存数量的减少,避免出现超卖的情况。比如,商品表中有一个字段为quantity表示当前该商 品的库存量。假设商品为华为mate40,id为1001,quantity=100个。如果不使用锁的情况下,操作方法如下所示
#第1步:查出商品库存
select quantity from items where id 1001;
#第2步:如果库存大于8,则根据商品信息生产订单
insert into orders (item_id) values(1001);
#第3步:修改商品的库存,num表示购买数量
update items set quantity = quantity-num where id 1001;
线程A | 线程B | |
---|---|---|
1 | step1 查询还有100部手机 | step1 查询还有100部手机 |
2 | step2 生成订单 | |
3 | step2 生成订单 | |
4 | step3 减库存1 | |
5 | step3 减库存2 |
这样写的话,在并发量小的公司没有大的问题,但是如果在高并发环境下可能出现以下问题
其中线程B此时已经下单并且减完库存,这个时候线程依然去执行tep3,就造成了超卖
。
我们使用悲观锁可以解决这个问题,商品信息从查询出来到修改,中间有一个生成订单的过程,使用悲观锁的原理就是,当我们在查询ites信息后就把当前的数据锁定,直到我们修改完毕后再解锁。那么整个过程中,因为数
据被锁定了,就不会出现有第三者来对其进行修改了。而这样做的前提是需要将要执行的SQL语句放在同一个事 务中,否则达不到锁定数据行的目的
。
修改如下:
#第1步:查出商品库存
select quantityl from items where id 1001 for update;
#第2步:如果库存大于0,则根据商品信息生产订单
insert into orders (item_id) values(1001);
#第3步:修改商品的库存,num表示购买数量
update items set quantity = quantity-num where id 1001;
select...for update
是MySQL中悲观锁。此时在 items表中,id为1001的那条数据就被我们锁定了,其他的要执行select quantity from items where id=1001 for update;
语句的事务必须等本次事务提交之后才能执行。这
样我们可以保证当前的数据不会被其它事务修改。
注意,当执行select quantity from items where id=1001 for update;
语句之后,如果在其他事务中执行select quantity from items where id=1001;语句
,并不会受第一个事务的影响,仍然可以正常查询出数据。
注意select....for update
语句执行过程中所有扫描的行都会被锁上,因此在MySQL中用悲观锁必须确定使用了
索引,而不是全表扫描,否则将会把整个表锁住。
悲观锁不适用的场景较多,它存在一些不足,因为悲观锁大多数情况下依靠数据库的锁机制来实现,以保证程序 的并发访问性,同时这样对数据库性能开销影响也很大,特别是长事务而言,这样的开销往往无法承受,这时就 需要乐观锁。
3.3.2 乐观锁(Optimistic Locking)
乐观锁认为对同一数据的并发操作不会总发生,属于小概率事件,不用每次都对数据上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,也就是不采用数据库自身的锁机制,而是通过程序来实现
。在程序上,我们可以采用 版本号机制
或者 CAS机制
实现。乐观锁适用于多读的应用类型,这样可以提高吞吐量。
在Java中 java.util.concurrent.atomic
包下的原子变量类就是使用了乐观锁的一种实现方式:CAS实现的。
乐观锁的版本号机制
在表中设计一个版本字段version
,第一次读的时候,会获取version字段的取值。然后对数据进行更 新或删除操作时,会执行UPDATE ... SET version=version+1 WHERE version=version
₀ 此时 如果已经有事务对这条数据进行了更改,修改就不会成功。
这种方式类似我们熟悉的SVN、CVS版本管理系统,当我们修改了代码进行提交时,首先会检查当前版本号与服 务器上的版本号是否一致,如果一致就可以直接提交,如果不一致就需要更新服务器上的最新代码,然后再进行 提交。
乐观锁的时间戳机制
时间戳和版本号机制一样,也是在更新提交的时候,将当前数据的时间戳和更新之前取得的时间戳进行 比较,如果两者一致则更新成功,否则就是版本冲突。
你能看到乐观锁就是程序员自己控制数据并发操作的权限,基本是通过给数据行增加一个戳(版本号或 者时间戳),从而证明当前拿到的数据是否最新。
秒杀案例2: 依然使用上面秒杀的案例,执行流程如下
#第1步:查出商品库有
select quantity from items where id 1001;
#第2步:如果库存大于0,则根据商品信息生产订单
insert into orders (item_id) values(1001);
#第3步:修改商品的库存,num表示购买数量
update items set quantity = quantity-num,version = version+1 where id 1001 and version = version};
注意,如果数据表是读写分离
的表,当matser表中写入的数据没有及时同步到slave表中时,会出现版本不一致
的问题。此时需要强制读取master表
中的数据(即将select语句放到事务中即可,这时候查询的就是master主库了)。
如果我们对同一条数据进行频繁的修改
的话,那么就会出现这么一种场景,每次修改都只有一个事务能更新成功,在业务感知上面就有大量的失败操作。我们把代码修改如下:
#第1步:查出商品库存
select quantity from items where id 1001;
#第2步:如果库存大于日,则根据商品信总生产订单
insert into orders (item_id) values(1001);
#第3步:修改商品的库存,um表示购买数量
update items set quantity = quantity-num where id =1001 and quantity-num>0;
这样就会使每次修改都能成功,而且不会出现超卖的现象。
3.3.3 两种锁的适用场景
从这两种锁的设计思想中,我们总结一下乐观锁和悲观锁的适用场景:
乐观锁
适合读操作多
的场景,相对来说写的操作比较少。它的优点在于程序实现
,不存在死锁
问题,不过适用场景也会相对乐观,因为它阻止不了除了程序以外的数据库操作。悲观锁
适合写操作多的场景
,因为写的操作具有排它性
。采用悲观锁的方式,可以在数据库层 面阻止其他事务对该数据的操作权限,防止读-写
和写-写
的冲突。
我们把乐观锁和悲观锁总结如下图:
3.4 按加锁的方式划分:显式锁、隐式锁
3.4.1 隐式锁
一个事务在执行INSERT
操作时,如果即将插入的间隙
已经被其他事务加了gap锁
,那么本次INSERT操作会阻
塞,并且当前事务会在该间隙上加一个插入意向锁
,否则一般情况下INSERT
操作是不加锁的。那如果一个事务
首先插入了一条记录(此时并没有在内存生产与该记录关联的锁结构),然后另一个事务:
-
立即使用
SELECT ... LOCK IN SHARE MODE
语句读取这条记录,也就是要获取这条记录的S锁,或者使用SELECT...FOR UPDATE语句读取这条记录,也就是要获取这条记录的X锁,怎么办?如果允许这种情况的发生,那么可能产生脏读
问题。 -
立即修改这条记录,也就是要获取这条记录的
X锁
,怎么办?如果允许这种情况的发生,那么可能产生脏写
问题。
这时候我们前边提过的事务id
又要起作用了。我们把聚簇索引和二级索引中的记录分开看一下:
-
情景一:对于聚簇索引记录来说,有一个
trx_id
隐藏列,该隐藏列记录着最后改动该记录的事务id
.那么如果在当前事务中新插入一条聚簇索引记录后,该记录的trx_id隐藏列
代表的的就是 当前事务的事务id ,如果其他事务此时想对该记录添加S锁或者X锁
时,首先会看一下该记录的trx_id
隐藏列代表的事务是否是当前的活跃事务,如果是的话,那么就帮助当前事务创建一个X 锁
(也就是为当前事务创建一个锁结构,is_waiting
属性是false),然后自己进入等待状态(也就是为自己也创建一个锁结构,is_waiting
属性是true )。 -
情景二:对于二级索引记录来说,本身并没有
trx_id隐藏列
,但是在二级索引页面的Page Header
部分有一个PAGE_MAX_TRX_ID
属性,该属性代表对该页面做改动的最大的事务id ,如 果PAGE_MAX_TRX_ID
属性值小于当前最小的活跃事务id ,那么说明对该页面做修改的事务都已 经提交了,否则就需要在页面中定位到对应的二级索引记录,然后回表找到它对应的聚簇索引记 录,然后再重复情景一的做法。
即:一个事务对新插入的记录可以不显式的加锁(生成一个锁结构),但是由于事务id
的存在,相当于加了一
个隐式锁。别的事务在对这条记录加S锁
或者X锁
时,由于隐式锁
的存在,会先帮助当前事务生成一个锁结构,然后自己再生成一个锁结构后进入等待状态。隐式锁是一种延迟加锁
的机制,从而来减少加锁的数量。
隐式锁在实际内存对象中并不含有这个锁信息。只有当产生锁等待时,隐式锁转化为显式锁。
InnoDB的insert操作,对插入的记录不加锁,但是此时如果另一个线程进行当前读,类似以下的用例,session2 会锁等待session1,那么这是如何实现的呢?
session 1:
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> insert INTO student VALUES(34,"周八","二班");
Query OK, 1 row affected (0.00 sec)
session 2:
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from student lock in share mode; #执行完,当前事务被阻塞
执行下述语句,输出结果:
mysql> SELECT * FROM performance_schema.data_lock_waits\G;
*************************** 1. row ***************************
ENGINE: INNODB
REQUESTING_ENGINE_LOCK_ID: 140562531358232:7:4:9:140562535668584
REQUESTING_ENGINE_TRANSACTION_ID: 422037508068888
REQUESTING_THREAD_ID: 64
REQUESTING_EVENT_ID: 6
REQUESTING_OBJECT_INSTANCE_BEGIN: 140562535668584
BLOCKING_ENGINE_LOCK_ID: 140562531351768:7:4:9:140562535619104
BLOCKING_ENGINE_TRANSACTION_ID: 15902
BLOCKING_THREAD_ID: 64
BLOCKING_EVENT_ID: 6
BLOCKING_OBJECT_INSTANCE_BEGIN: 140562535619104
1 row in set (0.00 sec)
隐式锁的逻辑过程如下:
A. InnoDB的每条记录中都一个隐含的trx_id字段,这个字段存在于聚簇索引的B+Tree中。
B. 在操作一条记录前,首先根据记录中的trx_id检查该事务是否是活动的事务(未提交或回滚)。如果是活动的事务,首先将 隐式锁 转换为显式锁 (就是为该事务添加一个锁)。
C. 检查是否有锁冲突,如果有冲突,创建锁,并设置为waiting状态。如果没有冲突不加锁,跳到E。
D. 等待加锁成功,被唤醒,或者超时。
E. 写数据,并将自己的trx_id写入trx_id字段。
3.4.2 显式锁
通过特定的语句进行加锁,我们一般称之为显示加锁,例如:
显示加共享锁:
select .... lock in share mode
显示加排它锁:
select .... for update
3.5 其它锁之:全局锁
全局锁就是对 整个数据库实例
加锁。当你需要让整个库处于 只读状态
的时候,可以使用这个命令,之后其他线程的以下语句会被阻塞:数据更新语句(数据的增删改)、数据定义语句(包括建表、修改表结构等)和更新类事务的提交语句。全局锁的典型使用 场景 是:做 全库逻辑备份
。
全局锁的命令:
Flush tables with read lock
3.6 其它锁之:死锁
3.6.1 概念
死锁是指两个或多个事务在同一资源上相互占用,并请求锁定对方占用的资源,从而导致恶性循环。死锁示例:
举例1:
举例2: 用户A给用户B转账100,在此同时,用户B也给用户A转账100。这个过程,可能导致死锁。
#事务1
update account set balance = balance - 100 where name ='A'; #操作1
update account set balance = balance + 100 where name ='B'; #操作3
#事务2
update account set balance = balance -100 where name ='B'; #操作2
update account set balance = balance + 100 where name ='A' ;#操作4
3.6.2 产生死锁的必要条件
- 两个或者两个以上事务
- 每个事务都已经持有锁并且申请新的锁
- 锁资源同时只能被同一个事务持有或者不兼容
- 事务之间因为持有锁和申请锁导致彼此循环等待
死锁的关键在于:两个(或以上)的Session加锁的顺序不一致。
3.6.3 如何处理死锁
方式1:等待,直到超时(innodb_lock_wait_timeout=50s
)。
即当两个事务互相等待时,当一个事务等待时间超过设置的阈值时,就将其回滚,另外事务继续进行。这种方法
简单有效,在innodb中,参数innodb_lock_wait_timeout
用来设置超时时间。
缺点:对于在线服务来说,这个等待时间往往是无法接受的。 那将此值修改短一些,比如1s,0.1s是否合适?不合适,容易误伤到普通的锁等待。
方式2:使用死锁检测进行死锁处理
方式1检测死锁大过被动,innodb还提供了wait-for graph
算法来主动进行死锁检测,每当加锁请求无法立即
满足需要并进入等待时,wait-for graph
算法都会被触发。
这是一种较为主动的死锁检测机制,要求数据库保存锁的信息链表和事务等待链表两部分信息。
基于这两个信息,可以绘制wait-for graph(等待图)
3.6.4 如何避免死锁
这时候,事务1在等待事务2释放id=2的行锁,而事务2在等待事务1释放id=1的行锁。 事务1和事务2在互 相等待对方的资源释放,就是进入了死锁状态。当出现死锁以后,有 两种策略:
- 第一种策略是,直接进入等待,直到超时。这个超时时间可以通过参数
innodb_lock_wait_timeout
来设置。 - 第二种种策略是,发起
死锁检测
,发现死锁后,主动回滚死锁链条中的某一个事务
(将持有最少行级排他锁的事务进行回滚),让其他事务得以继续执行。将参数innodb_deadlock_detect
设置为on
,表示开启这个逻辑。
第二种策略的成本分析
方法1: 如果你能确保这个业务一定不会出现死锁,可以临时把死锁检测关掉。但是这种操作本身带有 一定的风险,因为业务设计的时候一般不会把死锁当做一个严重错误,毕竟出现死锁了,就回滚,然后 通过业务重试一般就没问题了,这是业务无损的。而关掉死锁检测意味着可能会出现大量的超时,这是 业务有损的。
方法2:控制并发度。如果并发能够控制住,比如同一行同时最多只有10个线程在更新,那么死锁检测 的成本很低,就不会出现这个问题。 这个并发控制要做在数据库服务端。如果你有中间件,可以考虑在中间件实现;甚至有能力修改MySQL 源码的人,也可以做在MySQL里面。基本思路就是,对于相同行的更新,在进入引擎之前排队,这样在 InnoDB内部就不会有大量的死锁检测工作了。
4. 锁的内存结构
我们前面说对一条记录加锁的本质就是在内存中创建一个锁结构
与之关联,那么是不是一个事务对多条记录加锁,就要创建多个锁结构
呢?比方说事务T1
要执行下面这个语句:
# 事务T1
SELECT * FROM hero LOCK IN SHARE MODE;
很显然这条语句需要为hero表
中的所有记录进行加锁,那是不是需要为每条记录都生成一个锁结构
呢?其实理论上创建多个锁结构
没问题,反而更容易理解,但是谁知道你在一个事务里想对多少记录加锁呢,如果一个事务要获取10000条记录的锁,要生成10000个这样的结构也太亏了吧!所以设计InnoDB
的大佬本着勤俭节约的传统美德,决定在对不同记录加锁时,如果符合下面这些条件:
- 在同一个事务中进行加锁操作
- 被加锁的记录在同一个页面中
- 加锁的类型是一样的
- 等待状态是一样的
那么这些记录的锁就可以被放到一个锁结构
中。InnoDB
存储引擎中的锁结构
如下:
-
锁所在的事务信息
:不论是
表锁
还是行锁
,都是在事务执行过程中生成的,哪个事务生成了这个锁结构
,这里就记载着这个事务的信息。提示:
实际上这个所谓的锁所在的事务信息
在内存结构中只是一个指针而已,所以不会占用多大内存空间,通过指针可以找到内存中关于该事务的更多信息,比方说事务id是什么。下面介绍的所谓的索引信息
其实也是一个指针。 -
索引信息
:对于
行锁
来说,需要记录一下加锁的记录是属于哪个索引的。 -
表锁/行锁信息
:表锁结构
和行锁结构
在这个位置的内容是不同的:-
表锁:记载着这是对哪个表加的锁,还有其他的一些信息。
-
行锁:记载了三个重要的信息:
-
Space ID
:记录所在表空间。 -
Page Number
:记录所在页号。 -
n_bits
:对于行锁来说,一条记录就对应着一个比特位,一个页面中包含很多记录,用不同的比特位来区分到底是哪一条记录加了锁。为此在行锁结构的末尾放置了一堆比特位,这个n_bits
属性代表使用了多少比特位。提示:
并不是该页面中有多少记录,n_bits属性的值就是多少。为了让之后在页面中插入了新记录后也不至于重新分配锁结构,所以n_bits的值一般都比页面中记录条数多一些。
-
-
-
type_mode
:这是一个32位的数,被分成了
lock_mode
、lock_type
和rec_lock_type
三个部分,如下:-
锁的模式(
lock_mode
),占用低4位,可选的值如下:-
LOCK_IS
(十进制的0
):表示共享意向锁,也就是IS锁
。 -
LOCK_IX
(十进制的1
):表示独占意向锁,也就是IX锁
。 -
LOCK_S
(十进制的2
):表示共享锁,也就是S锁
。 -
LOCK_X
(十进制的3
):表示独占锁,也就是X锁
。 -
LOCK_AUTO_INC
(十进制的4
):表示AUTO-INC锁
。提示:
在InnoDB存储引擎中,LOCK_IS,LOCK_IX,LOCK_AUTO_INC都算是表级锁的模式,LOCK_S和LOCK_X既可以算是表级锁的模式,也可以是行级锁的模式。
-
-
锁的类型(
lock_type
),占用第5~8位,不过现阶段只有第5位和第6位被使用:LOCK_TABLE
(十进制的16
),也就是当第5个比特位置为1时,表示表级锁。LOCK_REC
(十进制的32
),也就是当第6个比特位置为1时,表示行级锁。
-
行锁的具体类型(
rec_lock_type
),使用其余的位来表示。只有在lock_type
的值为LOCK_REC
时,也就是只有在该锁为行级锁时,才会被细分为更多的类型:-
LOCK_ORDINARY
(十进制的0
):表示next-key锁
。 -
LOCK_GAP
(十进制的512
):也就是当第10个比特位置为1时,表示gap锁
。 -
LOCK_REC_NOT_GAP
(十进制的1024
):也就是当第11个比特位置为1时,表示正经记录锁
。 -
LOCK_INSERT_INTENTION
(十进制的2048
):也就是当第12个比特位置为1时,表示插入意向锁。 -
其他的类型:还有一些不常用的类型我们就不多说了。
怎么还没看见
is_waiting
属性呢?这主要还是设计InnoDB
的大佬太抠门了,一个比特位也不想浪费,所以他们把is_waiting
属性也放到了type_mode
这个32位的数字中: -
LOCK_WAIT
(十进制的256
) :也就是当第9个比特位置为1
时,表示is_waiting
为true
,也就是当前事务尚未获取到锁,处在等待状态;当这个比特位为0
时,表示is_waiting
为false
,也就是当前事务获取锁成功。
-
-
-
其他信息
:为了更好的管理系统运行过程中生成的各种锁结构而设计了各种哈希表和链表,为了简化讨论,我们忽略这部分信息~
-
一堆比特位
:如果是
行锁结构
的话,在该结构末尾还放置了一堆比特位,比特位的数量是由上面提到的n_bits
属性表示的。我们前面介绍InnoDB记录结构的时候说过,页面中的每条记录在记录头信息
中都包含一个heap_no
属性,伪记录Infimum
的heap_no
值为0
,Supremum
的heap_no
值为1
,之后每插入一条记录,heap_no
值就增1。锁结构
最后的一堆比特位就对应着一个页面中的记录,一个比特位映射一个heap_no
,不过为了编码方便,映射方式有点怪:提示:
这么怪的映射方式纯粹是为了敲代码方便,大家不要大惊小怪,只需要知道一个比特位映射到页内的一条记录就好了。
可能上面的描述大家觉得还是有些抽象,我们还是举个例子说明一下。比方说现在有两个事务T1
和T2
想对hero
表中的记录进行加锁,hero
表中记录比较少,假设这些记录都存储在所在的表空间号为67
,页号为3
的页面上,那么如果:
-
T1
想对number
值为15
的这条记录加S型正常记录锁
,在对记录加行锁之前,需要先加表级别的IS
锁,也就是会生成一个表级锁的内存结构,不过我们这里不关心表级锁,所以就忽略掉了~ 接下来分析一下生成行锁结构的过程:-
事务
T1
要进行加锁,所以锁结构的锁所在事务信息
指的就是T1
。 -
直接对聚簇索引进行加锁,所以索引信息指的其实就是
PRIMARY
索引。 -
由于是行锁,所以接下来需要记录的是三个重要信息:
-
Space ID
:表空间号为67
。 -
Page Number
:页号为3
。 -
n_bits
:我们的hero
表中现在只插入了5条用户记录,但是在初始分配比特位时会多分配一些,这主要是为了在之后新增记录时不用频繁分配比特位。其实计算n_bits
有一个公式:n_bits = (1 + ((n_recs + LOCK_PAGE_BITMAP_MARGIN) / 8)) * 8
其中
n_recs
指的是当前页面中一共有多少条记录(算上伪记录和在垃圾链表中的记录),比方说现在hero
表一共有7条记录(5条用户记录和2条伪记录),所以n_recs
的值就是7
,LOCK_PAGE_BITMAP_MARGIN
是一个固定的值64
,所以本次加锁的n_bits
值就是:n_bits = (1 + ((7 + 64) / 8)) * 8 = 72
-
type_mode
是由三部分组成的:-
lock_mode
,这是对记录加S锁
,它的值为LOCK_S
。 -
lock_type
,这是对记录进行加锁,也就是行锁,所以它的值为LOCK_REC
。 -
rec_lock_type
,这是对记录加正经记录锁
,也就是类型为LOCK_REC_NOT_GAP
的锁。另外,由于当前没有其他事务对该记录加锁,所以应当获取到锁,也就是LOCK_WAIT
代表的二进制位应该是0。综上所属,此次加锁的
type_mode
的值应该是:
type_mode = LOCK_S | LOCK_REC | LOCK_REC_NOT_GAP
也就是:
type_mode = 2 | 32 | 1024 = 1058
-
-
-
其他信息
-
一堆比特位
因为
number
值为15
的记录heap_no
值为5
,根据上面列举的比特位和heap_no
的映射图来看,应该是第一个字节从低位往高位数第6个比特位被置为1,就像这样:综上所述,事务
T1
为number
值为5的记录加锁生成的锁结构就如下图所示:
-
-
T2
想对number
值为3
、8
、15
的这三条记录加X型的next-key锁
,在对记录加行锁之前,需要先加表级别的IX
锁,也就是会生成一个表级锁的内存结构,不过我们这里不关心表级锁,所以就忽略掉了~现在
T2
要为3条记录加锁,number
为3
、8
的两条记录由于没有其他事务加锁,所以可以成功获取这条记录的X型next-key锁
,也就是生成的锁结构的is_waiting
属性为false
;但是number
为15
的记录已经被T1
加了S型正经记录锁
,T2
是不能获取到该记录的X型next-key锁
的,也就是生成的锁结构的is_waiting
属性为true
。因为等待状态不相同,所以这时候会生成两个锁结构
。这两个锁结构中相同的属性如下:-
事务
T2
要进行加锁,所以锁结构的锁所在事务信息
指的就是T2
。 -
直接对聚簇索引进行加锁,所以索引信息指的其实就是
PRIMARY
索引。 -
由于是行锁,所以接下来需要记录是三个重要信息:
-
Space ID
:表空间号为67
。 -
Page Number
:页号为3
。 -
n_bits
:此属性生成策略同T1
中一样,该属性的值为72
。 -
type_mode
是由三部分组成的:lock_mode
,这是对记录加X锁
,它的值为LOCK_X
。lock_type
,这是对记录进行加锁,也就是行锁,所以它的值为LOCK_REC
。rec_lock_type
,这是对记录加next-key锁
,也就是类型为LOCK_ORDINARY
的锁。
-
-
其他信息
-
为
number
为3
、8
的记录生成的锁结构
:-
type_mode
值。由于可以获取到锁,所以
is_waiting
属性为false
,也就是LOCK_WAIT
代表的二进制位被置0。所以:type_mode = LOCK_X | LOCK_REC |LOCK_ORDINARY
也就是
type_mode = 3 | 32 | 0 = 35
-
一堆比特位
因为
number
值为3
、8
的记录heap_no
值分别为3
、4
,根据上面列举的比特位和heap_no
的映射图来看,应该是第一个字节从低位往高位数第4、5个比特位被置为1,就像这样:综上所述,事务
T2
为number
值为3
、8
两条记录加锁生成的锁结构就如下图所示:
-
-
为
number
为15
的记录生成的锁结构
:-
type_mode
值。由于可以获取到锁,所以
is_waiting
属性为true
,也就是LOCK_WAIT
代表的二进制位被置1。所以:type_mode = LOCK_X | LOCK_REC |LOCK_ORDINARY | LOCK_WAIT
也就是
type_mode = 3 | 32 | 0 | 256 = 291
-
一堆比特位
因为
number
值为15
的记录heap_no
值为5
,根据上面列举的比特位和heap_no
的映射图来看,应该是第一个字节从低位往高位数第6个比特位被置为1,就像这样:综上所述,事务
T2
为number
值为15
的记录加锁生成的锁结构就如下图所示:综上所述,事务
T1
先获取number
值为15
的S型正经记录锁
,然后事务T2
获取number
值为3
、8
、15
的X型正经记录锁
共需要生成3个锁结构。
-
-
上面事务T2在对number值分别为3、8、15这三条记录加锁的情景中,是按照先对number值为3的记录加锁、再对number值为8的记录加锁,最后对number值为15的记录加锁的顺序进行的,如果我们一开始就对number值为15的记录加锁,那么该事务在为number值为15的记录生成一个锁结构后,直接就进入等待状态,就不为number值为3、8的两条记录生成锁结构了。在事务T1提交后会把在number值为15的记录上获取的锁释放掉,然后事务T2就可以获取该记录上的锁,这时再对number值为3、8的两条记录加锁时,就可以复用之前为number值为15的记录加锁时生成的锁结构了。
5. 锁监控
关于MySQL锁的监控,我们一般可以通过检查 innodb_row_lock
等状态变量来分析系统上的行锁的争夺情况
mysql> show status like 'innodb_row_lock%';
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| Innodb_row_lock_current_waits | 0 |
| Innodb_row_lock_time | 0 |
| Innodb_row_lock_time_avg | 0 |
| Innodb_row_lock_time_max | 0 |
| Innodb_row_lock_waits | 0 |
+-------------------------------+-------+
5 rows in set (0.01 sec)
对各个状态量的说明如下:
Innodb_row_lock_current_waits
:当前正在等待锁定的数量;Innodb_row_lock_time
:从系统启动到现在锁定总时间长度;(等待总时长)Innodb_row_lock_time_avg
:每次等待所花平均时间;(等待平均时长)Innodb_row_lock_time_max
:从系统启动到现在等待最常的一次所花的时间;Innodb_row_lock_waits
:系统启动后到现在总共等待的次数;(等待总次数)
对于这5个状态变量,比较重要的3个见上面。
尤其是当等待次数很高,而且每次等待时长也不小的时候,我们就需要分析系统中为什么会有如此多的等待,然后根据分析结果着手指定优化计划。
其他监控方法:
MySQL 把事务和锁的信息记录在了 information_schema
库中,涉及到的三张表分别是 INNODB_TRX、INNODB_LOCKS 和INNODB_LOCK_WAITS
。
MySQL5.7 及之前,可以通过information_schema.INNODB_LOCKS
查看事务的锁情况,但只能看到阻塞事 务的锁;如果事务并未被阻塞,则在该表中看不到该事务的锁情况。
MySQL8.0 删除了information_schema.INNODB_LOCKS
,添加了 performance_schema.data_locks
,可以通过performance_schema.data_locks
查看事务的锁情况,和MySQL5.7 及之前不同,performance_schema.data_locks
不但可以看到阻塞该事务的锁,还可以看到该事务所持有的锁。
同时,information_schema.INNODB_LOCK_WAITS
也被 performance_schema.data_lock_waits
所代 替。
我们模拟一个锁等待的场景,以下是从这三张表收集的信息
锁等待场景,我们依然使用记录锁中的案例,当事务2进行等待时,查询情况如下:
(1)查询正在被锁阻塞的sql语句。
SELECT * FROM information_schema.INNODB_TRX\G;
重要属性代表含义已在上述中标注。
(2)查询锁等待情况
SELECT * FROM data_lock_waits\G;
*************************** 1. row ***************************
ENGINE: INNODB
REQUESTING_ENGINE_LOCK_ID: 139750145405624:7:4:7:139747028690608
REQUESTING_ENGINE_TRANSACTION_ID: 13845 #被阻塞的事务ID
REQUESTING_THREAD_ID: 72
REQUESTING_EVENT_ID: 26
REQUESTING_OBJECT_INSTANCE_BEGIN: 139747028690608
BLOCKING_ENGINE_LOCK_ID: 139750145406432:7:4:7:139747028813248
BLOCKING_ENGINE_TRANSACTION_ID: 13844 #正在执行的事务ID,阻塞了13845
BLOCKING_THREAD_ID: 71
BLOCKING_EVENT_ID: 24
BLOCKING_OBJECT_INSTANCE_BEGIN: 139747028813248
1 row in set (0.00 sec)
(3)查询锁的情况
mysql > SELECT * from performance_schema.data_locks\G;
*************************** 1. row ***************************
ENGINE: INNODB
ENGINE_LOCK_ID: 139750145405624:1068:139747028693520
ENGINE_TRANSACTION_ID: 13847
THREAD_ID: 72
EVENT_ID: 31
OBJECT_SCHEMA: atguigu
OBJECT_NAME: user
PARTITION_NAME: NULL
SUBPARTITION_NAME: NULL
INDEX_NAME: NULL
OBJECT_INSTANCE_BEGIN: 139747028693520
LOCK_TYPE: TABLE
LOCK_MODE: IX
LOCK_STATUS: GRANTED
LOCK_DATA: NULL
*************************** 2. row ***************************
ENGINE: INNODB
ENGINE_LOCK_ID: 139750145405624:7:4:7:139747028690608
ENGINE_TRANSACTION_ID: 13847
THREAD_ID: 72
EVENT_ID: 31
OBJECT_SCHEMA: atguigu
OBJECT_NAME: user
PARTITION_NAME: NULL
SUBPARTITION_NAME: NULL
INDEX_NAME: PRIMARY
OBJECT_INSTANCE_BEGIN: 139747028690608
LOCK_TYPE: RECORD
LOCK_MODE: X,REC_NOT_GAP
LOCK_STATUS: WAITING
LOCK_DATA: 1
*************************** 3. row ***************************
ENGINE: INNODB
ENGINE_LOCK_ID: 139750145406432:1068:139747028816304
ENGINE_TRANSACTION_ID: 13846
THREAD_ID: 71
EVENT_ID: 28
OBJECT_SCHEMA: atguigu
OBJECT_NAME: user
PARTITION_NAME: NULL
SUBPARTITION_NAME: NULL
INDEX_NAME: NULL
OBJECT_INSTANCE_BEGIN: 139747028816304
LOCK_TYPE: TABLE
LOCK_MODE: IX
LOCK_STATUS: GRANTED
LOCK_DATA: NULL
*************************** 4. row ***************************
ENGINE: INNODB
ENGINE_LOCK_ID: 139750145406432:7:4:7:139747028813248
ENGINE_TRANSACTION_ID: 13846
THREAD_ID: 71
EVENT_ID: 28
OBJECT_SCHEMA: atguigu
OBJECT_NAME: user
PARTITION_NAME: NULL
SUBPARTITION_NAME: NULL
INDEX_NAME: PRIMARY
OBJECT_INSTANCE_BEGIN: 139747028813248
LOCK_TYPE: RECORD
LOCK_MODE: X,REC_NOT_GAP
LOCK_STATUS: GRANTED
LOCK_DATA: 1
4 rows in set (0.00 sec)
ERROR:
No query specified
从锁的情况可以看出来,两个事务分别获取了IX锁,我们从意向锁章节可以知道,IX锁互相时兼容的。
所以这里不会等待,但是事务1同样持有X锁,此时事务2也要去同一行记录获取X锁,他们之间不兼容,导致等待的情况发生。
附录
间隙锁加锁规则(共11个案例)
间隙锁
是在可重复读隔离级别
下才会生效的:next-key lock
实际上是由间隙锁加行锁
实现的,如果切换 到读提交隔离级别(read-committed)的话,就好理解了,过程中去掉间隙锁的部分,也就是只剩下行锁 的部分。而在读提交隔离级别下间隙锁就没有了,为了解决可能出现的数据和日志不一致问题,需要把 binlog格式设置为row。也就是说,许多公司的配置为:读提交隔离级别加binlog_format=row
。业务不 需要可重复读的保证,这样考虑到读提交下操作数据的锁范围更小(没有间隙锁),这个选择是合理的。
next-key lock的加锁规则
总结的加锁规则里面,包含了两个““原则””、两个“ “优化””和一个“bug”
。
-
原则1:加锁的基本单位是next-key lock。next-key lock是前开后闭区间。
-
原则2:查找过程中访问到的对象才会加锁。任何辅助索引上的锁,或者非索引列上的锁,最终 都要回溯到主键上,在主键上也要加一把锁。
-
优化1:索引上的等值直询,给唯一索引加锁的时候,next-key lock退化为行锁。也就是说如果 InnoDB扫描的是一个主键、或是一个唯一索引的话,那InnoDB只会采用行锁方式来加锁
-
优化2:索引上(不一定是唯一索引)的等值查询,向右遍历时且最后一个值不满足等值条件的 时候,next-keylock退化为间隙锁。
-
一个bug:唯一索引上的范围杳询会访问到不满足条件的第一个值为止。
我们以表test作为例子,建表语句和初始化语句如下:其中id为主键索引
CREATE TABLE test(
id int(11) NOT NULL,
'coir` int(11) DEFAULT NULL,
'co12' int(11) DEFAULT NULL,
PRIMARY KEY ('id`),
KEY c (`c` )) ENGINE=InnoDB;
insert into test values(0,0,0),(5,5,5), (10,10,10),(15,15,15),(20,20,20),(25,25,25);
案例一:唯一索引等值查询间隙锁
由于表test中没有id=7的记录
根据原则1,加锁单位是next-key lock, session A加锁范围就是(5,10];同时根据优化2 ,这是一个等 值查询(id=7),而id=10不满足查询条件,next-key lock退化成间隙锁,因此最终加锁的范围是(5,10)
案例二:非唯一索引等值查询锁
这里session A要给索引coll上coll=5的这一行加上读锁。
- 根据原则1,加锁单位是next-key lock ,左开右闭,5是闭上的,因此会给(0,5]加上next-key lock
- 要注意c是普通索引,因此仅访问c=5这一条记录是不能马上停下来的(可能有811=5的其他记 录),需要向右遍历,查到c=10才放弃。根据原则2,访问到的都要加锁,因此要给(5,10]力口 next-key lock。
- 但是同时这个符合优化2:等值判断,向右遍历,最后T值不满足811=5这个等值条件,因此 退化成间隙锁(5,10) .
- 根据原则2,只有访问到的对象才会加锁,这个查询使用覆盖索引,并不需要访问主键索引,所 以主键索引上没有加任何锁,这就是为什么session B的update语句可以执行完成。
但session C要插入T (7,7,7)的记录,就会被session A的间隙锁(5,10)锁住这个例子说明,锁是加在 索引上的。
执行for update时,系统会认为你接下来要更新数据,因此会顺便给主键索引上满足条件的行加上行 锁。 如果你要用lock in share mode来给行加读锁避免数据被更新的话,就必须得绕过覆盖索引的优化,因为 覆盖索引不会访问主键索引,不会给主键索引上加锁
案例三:主键索引范围查询锁
上面两个例子是等值查询的,这个例子是关于范围查询的,也就是说下面的语句
select * from test where id=10 for update
select * from tets where id>=10 and id<11 for update;
这两条查语句肯定是等价的,但是它们的加锁规则不太一样
- 开始执行的时候,要找到第一个id=10的行,因此本该是next-key lock(5,10]。根据优化1,主健 id上的等值条件,退化成行锁,只加了 id=10这一行的行锁。
- 它是范围查询,范围直找就往后继续找,找到id=15这一行停下来,不满足条件,因此需要加 next-key lock(10,15]。
session A这时候锁的范围就是主键索引上,行锁id=10和next-key lock(10,15] ₒ首次session A定位查找 id=10的行的时候,是当做等值查询来判断的,而向右扫描到id=15的时候,用的是范围直询判断。
案例四:非唯一索引范围查询锁
与案例三不同的是,案例四中查询语句的where部分用的是字段c,它是普通索引 这两条查语句肯定是等价的,但是它们的加锁规则不太一样
在第一次用coll=10定位记录的时候,索引c上加了 (5,10]这个next-key lock后,由于索引coll是非唯 一索引,没有优化规则,也就是说不会蜕变为行锁,因此最终sesionA加的锁是,索引c上的(5,10]和 (10,15]这两个 next-keylock。
这里需要扫描到811:15才停止扫描,是合理的,因为InnoDB要扫至I」811=15,才知道不需要继续往后 找了。
案例五:唯一索引范围查询锁bug
session A是一个范围查询,按照原则1的话,应该是索引id上只加(10,15]这个next-key lock ,并且因 为id是唯一键,所以循环判断到id=15这一行就应该停止了。
但是实现上,InnoDB会往前扫描到第一个不满足条件的行为止,也就是id=20。而且由于这是个范围扫 描,因此索引id上的(15,20]这个next-key lock也会被锁上。照理说,这里锁住id=20这一行的行为,其 实是没有必要的。因为扫描到id=15 ,就可以确定不用往后再找了。
案例六:非唯一索引上存在“ “等值"”的例子
这里,我给表t插入一条新记录:insert into t values(30,10,30)也就是说,现在表里面有两个c=10的行 但是它们的主键值id是不同的(分别是10和30),因此这两个c=10的记录之间,也是有间隙的。
这次我们用delete语句来验证。注意,delete语句加锁的逻辑,其实跟select…for update是类|以的, 也就是我在文章开始总结的两个“原则”、两个“优化”和一个“bug”。
这时,session A在遍历的时候,先访问第一个coll=10的记录。同样地,根据原则1 ,这里加的是 (coll=5,id=5)至U (coll=10,id=10)这个 next-key lock。
由于c是普通索引,所以继续向右直找,直到碰到(811=15,id=15)这一行循环才结束。根据优化2,这是 一个等值查询,向右直找到了不满足条件的行,所以会退化成(811=10,id=10)到(coll=15,id=15)的间隙 这个delete语句在索引c上的加锁范围,就是上面图中蓝色区域覆盖的部分。这个蓝色区域左右两边都 是虚线,表示开区间,即(coll=5,id=5)和(coll=15,id=15)这两行上都没有锁
案例七:limit语句加锁
例子6也有一个对照案例,场景如下所示:
session A的delete语句加了 limit 2。你知道表t里c=10的记录其实只有两条,因此加不加limit 2 ,删 除的效果都是一样的。但是加锁效果却不一样
这是因为,案例七里的加lete语句明确加了 limit 2的限制,因此在遍扉U (coll=10, id=30)这一行之后, 满足条件的语句已经有两条,循环就结束了。因此,索引coll上的加锁范围就变成了从(coll=5,id=5) 到(coll=10,id=30)这个前开后闭区间,如下图所示:
这个例子对我们实践的指导意义,在删除数据的时候尽量加 limit
这样不仅可以控制删除数据的条数,让操作更安全,还可以减小加锁的范围。
案例八:一个死锁的例子
- session A启动事务后执行查询语句加lock in share mode ,在索引coll上加了 next-keylock(5,10]和 间隙锁(10,15)(索引向右遍历退化为间隙锁);
- session B的update语句也要在索引c上加next-key lock(5,10],进入锁等待;实际上分成了两步, 先是加(5,10)的间隙锁,加锁成功;然后加811:10的行锁,因为sessionA_t已经给这行加上了读 锁,此时申请死锁时会被阻塞
- 然后session A要再插入(8,8⑻这一行,被session B的间隙锁锁住。由于出现了死锁,InnoDB让 session B 回滚
案例九:order by索引排序的间隙锁1
如下面一条语句
begin;
select * from test where id>9 and id<12 order by id desc for update;
下图为这个表的索引id的示意图。
- 首先这个查询语句的语义是。rder by id desc,要拿到满足条件的所有行,优化器必须先找到“第 一个id<12的值”。
- 这个过程是通过索引树的搜索过程得到的,在引擎内部,其实是要找到id=12的这个值,只是最终 没找到,但找到了 (10,15)这个间隙。(id=15不满足条件,所以next-key lock退化为了间隙锁(10, 15)。)
- 然后向左遍历,在遍历过程中,就不是等值查询了,会扫描到id二5这一行,又因为区间是左开右 闭的,所以会加一个next-key lock (0,5]。也就是说,出丸行过程中,通过树搜索的方式定位记录 的时候,用的是“等值查询”的方法。
案例十:order by索引排序的间隙锁2
- 由于是order by coll desc ,第一个要定位的是索引coll上"最右边的ⁿcoll=20的行。这是一个非 唯一索引的等值有询: 左开右闭区间,首先加上next-key lock (15,20]。向右遍历,coll=25不满足条件,退化为间隙锁所以会 加上间隙锁(20,25)和 next-key lock (15,20] ₒ
- 在索引coll上向左遍历,要扫描到coll=10才停下来。同时又因为左开右闭区间,所以next-key lock会加到(5,10],这正是阻塞session B的insert语句的原因。
- 在扫描过程中,811=20、811=15、coll=10这三行都存在值,由于是select"所以会在主键 id上加三个行锁。因此,session A的select语句锁的范围就是:
- 索引 coll 上(5,25);
- 主键索引上id=15、20两个行锁。
案例十一:update修改数据的例子-先插入后删除
注意:根据coll>5第lj的第一个记录是coll=10 ,因此不会加(0,5]这个next-key lock ₒ session A 的加锁范围是索引 coll 上的(5,10] ₓ (10,15] . (15,20]、(20,25]和(25,supremum]。 之后session B的第一个update语句,要J巴coll=5改成coll=l,你可以理解为两步:
- 插入(co 11=1, id=5)这个记录;
- 删除(coll=5, id=5)这个记录。 通过这个操作,sessionA的加锁范围变成了图7所示的样子:
好,接下来session B要执行update t set coll = 5 where coll = 1这个语句了,一样地可以拆成两步:
- 插入(coll=5, id=5)这个记录;
- 删除(coll=l,id=5)这个记录。第一步试图在已经加了间隙锁的(1,10)中插入数据,所以就被堵住 了。
参考文章
MySQL从入门到精通
《MySQL技术内幕:InnoDB存储引擎(第2版)》
《MySQL是怎样运行的 从根儿上理解MySQL》
《数据库索引设计与优化》