第14章 MySQL事务日志
事务有4种特性:原子性、一致性、隔离性和持久性。那么事务的四种特性到底是基于什么机制实现呢?
- 事务的隔离性由
锁机制
实现。 - 而事务的原子性、一致性和持久性由事务的 redo 日志和undo 日志来保证。
- REDO LOG 称为
重做日志
,提供再写入操作,恢复提交事务修改的页操作,用来保证事务的持久性。 - UNDO LOG 称为
回滚日志
,回滚行记录到某个特定版本,用来保证事务的原子性、一致性。
- REDO LOG 称为
1. redo日志
1.1 为什么需要REDO日志
一方面,缓冲池可以帮助我们消除CPU和磁盘之间的鸿沟,checkpoint机制可以保证数据的最终落盘,然而由于checkpoint并不是每次变更的时候就触发
的,而是master线程隔一段时间去处理的。所以最坏的情况就是事务提交后,刚写完缓冲池,数据库宕机了,那么这段数据就是丢失的,无法恢复。
另一方面,事务包含持久性
的特性,就是说对于一个已经提交的事务,在事务提交后即使系统发生了崩溃,这个事务对数据库中所做的更改也不能丢失。
那么如何保证这个持久性呢?一个简单的做法
:在事务提交完成之前把该事务所修改的所有页面都刷新到磁盘,但是这个简单粗暴的做法有些问题
另一个解决的思路
:我们只是想让已经提交了的事务对数据库中数据所做的修改永久生效,即使后来系统崩溃,在重启后也能把这种修改恢复出来。所以我们其实没有必要在每次事务提交时就把该事务在内存中修改过的全部页面刷新到磁盘,只需要把修改
了哪些东西记录一下
就好。比如,某个事务将系统表空间中第10号
页面中偏移量为100
处的那个字节的值1
改成2
。我们只需要记录一下:将第0号表空间的10号页面的偏移量为100处的值更新为 2 。
1.2 REDO日志的好处、特点
1. 好处
- redo日志降低了刷盘频率
- redo日志占用的空间非常小
2. 特点
- redo日志是顺序写入磁盘的
- 事务执行过程中,redo log不断记录
1.3 redo的组成
Redo log可以简单分为以下两个部分:
重做日志的缓冲 (redo log buffer)
,保存在内存中,是易失的。
参数设置:innodb_log_buffer_size:
redo log buffer 大小,默认16M
,最大值是4096M,最小值为1M。
重做日志文件 (redo log file)
,保存在硬盘中,是持久的。
1.4 redo的整体流程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-z0euMmzU-1656249929126)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204031147714.png)]
第1步:先将原始数据从磁盘中读入内存中来,修改数据的内存拷贝
第2步:生成一条重做日志并写入redo log buffer,记录的是数据被修改后的值
第3步:当事务commit时,将redo log buffer中的内容刷新到 redo log file,对 redo log file采用追加写的方式
第4步:定期将内存中修改的数据刷新到磁盘中
Write-Ahead Log(预先日志持久化):在持久化一个数据页之前,先将内存中相应的日志页持久化。
1.5 redo log的刷盘策略
redo log buffer刷盘到redo log file的过程并不是真正的刷到磁盘中去,只是刷入到文件系统缓存
(page cache)中去(这是现代操作系统为了提高文件写入效率做的一个优化),真正的写入会交给系统自己来决定(比如page cache足够大了)。那么对于InnoDB来说就存在一个问题,如果交给系统来同步,同样如果系统宕机,那么数据也丢失了(虽然整个系统宕机的概率还是比较小的)。
针对这种情况,InnoDB给出innodb_flush_log_at_trx_commit
参数,该参数控制 commit提交事务时,如何将 redo log buffer 中的日志刷新到 redo log file 中。它支持三种策略:
设置为0
:表示每次事务提交时不进行刷盘操作。(系统默认master thread每隔1s进行一次重做日志的同步)设置为1
:表示每次事务提交时都将进行同步,刷盘操作(默认值
)设置为2
:表示每次事务提交时都只把 redo log buffer 内容写入 page cache,不进行同步。由os自己决定什么时候同步到磁盘文件。
1.6 不同刷盘策略演示
1. 流程图
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-K9RFHuqn-1656249929127)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204031152952.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mvMvrLmk-1656249929127)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204031152607.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Yl1jNEsI-1656249929128)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204031153931.png)]
1.7 写入redo log buffer过程
1. 补充概念:Mini-Transaction
一个事务可以包含若干条语句,每一条语句其实是由若干个mtr
组成,每一个mtr
又可以包含若干条redo日志
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UyLIIlj0-1656249929128)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204040912119.png)]
2. redo 日志写入log buffer
不同的事务可能是并发
执行的,所以事务T1
、事务T2
之间的mtr
可能是交替执行
的。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xiSUwDGI-1656249929128)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204040915708.png)]
1.8 redo log file
1. 相关参数设置
-
innodb_log_group_home_dir
:指定 redo log 文件组所在的路径,默认值为./
,表示在数据库的数据目录下。MySQL的默认数据目录(var/lib/mysql
)下默认有两个名为ib_logfile0
和ib_logfile1
的文件,log buffer中的日志默认情况下就是刷新到这两个磁盘文件中。此redo日志文件位置还可以修改。 -
innodb_log_files_in_group
:指明redo log file的个数,命名方式如:ib_logfile0,ib_logfile1… ib_logfilen。默认2个,最大100个。 -
innodb_flush_log_at_trx_commit
:控制 redo log 刷新到磁盘的策略,默认为1
。 -
innodb_log_file_size
:单个 redo log 文件设置大小,默认值为 48M 。最大值为512G,注意最大值指的是整个 redo log 系列文件之和,即(innodb_log_files_in_group * innodb_log_file_size )不能大于最大值512G。
2. 日志文件组
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gE0uYGg5-1656249929129)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204040920532.png)]
3. checkpoint
如果 write pos 追上 checkpoint ,表示日志文件组满了,这时候不能再写入新的 redo log记录,MySQL 得停下来,清空一些记录,把 checkpoint 推进一下。
2. Undo日志
redo log是事务持久性的保证,undo log是事务原子性的保证。在事务中更新数据
的前置操作
其实是要先写入一个 undo log 。
2.1 如何理解Undo日志
事务需要保证原子性
,也就是事务中的操作要么全部完成,要么什么也不做。但有时候事务执行到一半会出现一些情况,比如:
- 情况一:事务执行过程中可能遇到各种错误,比如
服务器本身的错误
,操作系统错误
,甚至是突然断电
导致的错误。 - 情况二:程序员可以在事务执行过程中手动输入
ROLLBACK
语句结束当前事务的执行。
以上情况出现,我们需要把数据改回原先的样子,这个过程称之为回滚
,这样就可以造成一个假象:这个事务看起来什么都没做,所以符合原子性
要求。
2.2 Undo日志的作用
- 作用1:回滚数据
- 作用2:MVCC(详情看第16章)
2.3 undo的存储结构
1. 回滚段与undo页
InnoDB对undo log的管理采用段的方式,也就是回滚段(rollback segment)
。每个回滚段记录了1024
个undo log segment
,而在每个undo log segment段中进行undo页
的申请。
2. 回滚段与事务
-
每个事务只会使用一个回滚段,一个回滚段在同一时刻可能会服务于多个事务。
-
当一个事务开始的时候,会制定一个回滚段,在事务进行的过程中,当数据被修改时,原始的数据会被复制到回滚段。
-
在回滚段中,事务会不断填充盘区,直到事务结束或所有的空间被用完。如果当前的盘区不够用,事务会在段中请求扩展下一个盘区,如果所有已分配的盘区都被用完,事务会覆盖最初的盘区或者在回滚段允许的情况下扩展新的盘区来使用。
-
回滚段存在于undo表空间中,在数据库中可以存在多个undo表空间,但同一时刻只能使用一个undo表空间。
-
当事务提交时,InnoDB存储引擎会做以下两件事情:
- 将undo log放入列表中,以供之后的purge操作
- 判断undo log所在的页是否可以重用,若可以分配给下个事务使用
3. 回滚段中的数据分类
-
未提交的回滚数据(uncommitted undo information)
-
已经提交但未过期的回滚数据(committed undo information)
-
事务已经提交并过期的数据(expired undo information)
2.4 undo的类型
在InnoDB存储引擎中,undo log分为:
- insert undo log
- update undo log
2.5 undo log的生命周期
1. 简要生成过程
只有Buffer Pool的流程:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xT0CzsW6-1656249929129)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204040937761.png)]
有了Redo Log和Undo Log之后:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Qno9mz5n-1656249929130)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204040938657.png)]
2. 详细生成过程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1phNsJFq-1656249929130)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204040939231.png)]
当我们执行INSERT时:
begin;
INSERT INTO user (name) VALUES ("tom");
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VTOFGl6n-1656249929130)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204040940543.png)]
当我们执行UPDATE时:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Sm32yPKN-1656249929131)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204040941624.png)]
UPDATE user SET id=2 WHERE id=1;
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4YoJgj57-1656249929131)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204040941449.png)]
3. undo log是如何回滚的
以上面的例子来说,假设执行rollback,那么对应的流程应该是这样:
-
通过undo no=3的日志把id=2的数据删除
-
通过undo no=2的日志把id=1的数据的deletemark还原成0
-
通过undo no=1的日志把id=1的数据的name还原成Tom
-
通过undo no=0的日志把id=1的数据删除
4. undo log的删除
- 针对于insert undo log
因为insert操作的记录,只对事务本身可见,对其他事务不可见。故该undo log可以在事务提交后直接删除,不需要进行purge操作。
- 针对于update undo log
该undo log可能需要提供MVCC机制,因此不能在事务提交时就进行删除。提交时放入undo log链表,等待purge线程进行最后的删除。
2.6 小结
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ws93LYmC-1656249929131)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204040944948.png)]
undo log是逻辑日志,对事务回滚时,只是将数据库逻辑地恢复到原来的样子。
redo log是物理日志,记录的是数据页的物理变化,undo log不是redo log的逆过程。
第15章 锁
1. 概述
在数据库中,除传统的计算资源(如CPU、RAM、I/O等)的争用以外,数据也是一种供许多用户共享的资源。为保证数据的一致性,需要对并发操作进行控制
,因此产生了锁
。同时锁机制
也为实现MySQL的各个隔离级别提供了保证。 锁冲突 也是影响数据库并发访问性能
的一个重要因素。所以锁对数据库而言显得尤其重要,也更加复杂。
2. MySQL并发事务访问相同记录
2.1 读-读情况
读-读
情况,即并发事务相继读取相同的记录
。读取操作本身不会对记录有任何影响,并不会引起什么问题,所以允许这种情况的发生。
2.2 写-写情况
写-写
情况,即并发事务相继对相同的记录做出改动。
在这种情况下会发生脏写
的问题,任何一种隔离级别都不允许这种问题的发生。所以在多个未提交事务相继对一条记录做改动时,需要让它们排队执行
,这个排队的过程其实是通过锁
来实现的。
2.3 读-写或写-读情况
读-写
或写-读
,即一个事务进行读取操作,另一个进行改动操作。这种情况下可能发生脏读
、不可重复读
、幻读
的问题。
2.4 并发问题的解决方案
怎么解决脏读
、不可重复读
、幻读
这些问题呢?其实有两种可选的解决方案:
- 方案一:读操作利用多版本并发控制(
MVCC
,下章讲解),写操作进行加锁
。
所谓的MVCC
,就是生成一个ReadView
,通过ReadView找到符合条件的记录版本(历史版本由undo日志
构建)。查询语句只能读
到在生成ReadView之前已提交事务所做的更改
,在生成ReadView之前未提交的事务或者之后才开启的事务所做的更改是看不到的。而写操作
肯定针对的是最新版本的记录
,读记录的历史版本和改动记录的最新版本本身并不冲突,也就是采用MVCC时,读-写
操作并不冲突。
普通的SELECT语句在READ COMMITTED和REPEATABLE READ隔离级别下会使用到MVCC读取记录。
- 在
READ COMMITTED
隔离级别下,一个事务在执行过程中每次执行SELECT操作时都会生成一个ReadView,ReadView的存在本身就保证了事务不可以读取到未提交的事务所做的更改
,也就是避免了脏读现象;- 在
REPEATABLE READ
隔离级别下,一个事务在执行过程中只有第一次执行SELECT操作
才会生成一个ReadView,之后的SELECT操作都复用
这ReadView,这样也就避免了不可重复读和幻读的问题。
-
方案二:读、写操作都采用
加锁
的方式。 -
小结对比发现:
- 采用
MVCC
方式的话,读-写
操作彼此并不冲突,性能更高
。 - 采用
加锁
方式的话,读-写
操作彼此需要排队执行
,影响性能。
- 采用
一般情况下我们当然愿意采用MVCC
来解决读-写
操作并发执行的问题,但是业务在某些特殊情况下,要求必须采用加锁
的方式执行。
3. 锁的不同角度分类
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Gt0RwIB6-1656249929132)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204050933339.png)]
3.1 从数据操作的类型划分:读锁、写锁
读锁
:也称为共享锁
、英文用S
表示。针对同一份数据,多个事务的读操作可以同时进行而不会互相影响,相互不阻塞的。写锁
:也称为排他锁
、英文用X
表示。当前写操作没有完成前,它会阻断其他写锁和读锁。这样就能确保在给定的时间里,只有一个事务能执行写入,并防止其他用户读取正在写入的同一资源。
需要注意的是对于 InnoDB 引擎来说,读锁和写锁可以加在表上,也可以加在行上。
1. 锁定读
在采用加锁
方式解决脏读
、不可重复读
、幻读
这些问题时,读取一条记录时需要获取该记录的S锁
,其实是不严谨的,有时候需要在读取记录时就获取记录的X锁
,来禁止别的事务读写该记录,为此MySQL提出了两种比较特殊的SELECT
语句格式:
- 对读取的记录加
S锁
:
SELECT ... LOCK IN SHARE MODE;
# 或
SELECT ... FOR SHARE; #(8.0新增语法)
- 对读取的记录加
X锁
:
SELECT ... FOR UPDATE;
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:如果查询的行已经加锁,只返回结果中不包含被锁定的行
2. 写操作
DELETE
:对一条记录做DELETE操作的过程其实是先在B+
树中定位到这条记录的位置,然后获取这条记录的X锁
,再执行delete mark
操作。UPDATE
:在对一条记录做UPDATE操作时分为三种情况:- 情况1:未修改该记录的键值,并且被更新的列占用的存储空间在修改前后未发生变化。则先在
B+
树中定位到这条记录的位置,然后再获取一下记录的X锁
,最后在原纪录的位置进行修改操作。 - 情况2:未修改该记录的键值,并且至少有一个被更新的列占用的存储空间在修改前后发生变化。则先在
B+
树中定位到这条记录的位置,然后获取一下记录的X锁
,将该记录彻底删除掉(就是把记录彻底移入垃圾链表),最后再插入一条新记录。新插入的记录由INSERT
操作提供的隐式锁
进行保护。 - 情况3:修改该记录的键值,则相当于在原纪录上做
DELECT
操作之后再来一次INSERT
操作。
- 情况1:未修改该记录的键值,并且被更新的列占用的存储空间在修改前后未发生变化。则先在
INSERT
:一般情况下,新插入一条记录的操作并不加锁,通过一种称之为隐式锁
的结构来保护这条新插入的记录在本事务提交前不被别的事务访问。
3.2 从数据操作的粒度划分:表级锁、页级锁、行锁
1. 表锁(Table Lock)
该锁会锁定整张表,它是MySQL中最基本的锁策略,并不依赖于存储引擎
,并且表锁是开销最少
的策略。由于表级锁一次会将整个表锁定,所以可以很好的避免死锁
的问题。当然,锁的粒度大所带来最大的负面影响就是出现锁资源争用的概率也会最高,导致并发率大打折扣
。
① 表级别的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锁
。
总结:MyISAM在执行查询语句(SELECT)前,会给涉及的所有表加读锁,在执行增删改操作前,会给涉及的表加写锁。InnoDB
存储引擎是不会为这个表添加表级别的读锁
或者写锁
的。
② 意向锁 (intention lock)
InnoDB 支持多粒度锁(multiple granularity locking)
,它允许行级锁
与表级锁
共存,而意向锁就是其中的一种表锁
。
1、意向锁的存在是为了协调行锁和表锁的关系,支持多粒度(表锁与行锁)的锁并存。
2、意向锁是一种不与行级锁冲突的表级锁
,这一点非常重要。
3、表明“某个事务正在某些行持有了锁或该事务准备去持有锁”
意向锁分为两种:
- 意向共享锁(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;
即:意向锁是由存储引擎自己维护的
,用户无法手动操作意向锁,在为数据行加共享 / 排他锁之前,InooDB 会先获取该数据行所在数据表的对应意向锁
。
1. 意向锁要解决的问题
现在有两个事务,分别是T1和T2,其中T2试图在该表级别上应用共享或排它锁,如果没有意向锁存在,那么T2就需要去检查各个页或行是否存在锁;如果存在意向锁,那么此时就会受到由T1控制的表级别意向锁的阻塞
。T2在锁定该表前不必检查各个页或行锁,而只需检查表上的意向锁。简单来说就是给更大一级级别的空间示意里面是否已经上过锁。
在数据表的场景中,如果我们给某一行数据加上了排它锁,数据库会自动给更大一级的空间,比如数据页或数据表加上意向锁,告诉其他人这个数据页或数据表已经有人上过排它锁了,这样当其他人想要获取数据表排它锁的时候,只需要了解是否有人已经获取了这个数据表的意向排它锁即可。
- 如果事务想要获取数据表中某些记录的共享锁,就需要在数据表上
添加意向共享锁
- 如果事务想要获取数据表中某些记录的排它锁,就需要在数据表上
添加意向排他锁
这时,意向锁会告诉其他事务已经有人锁定了表中的某些记录。
③ 自增锁(AUTO-INC锁)
1. “Simple inserts” (简单插入)
可以预先确定要插入的行数
(当语句被初始处理时)的语句。包括没有嵌套子查询的单行和多行INSERT...VALUES()
和REPLACE
语句。
2. “Bulk inserts” (批量插入)
事先不知道要插入的行数
(和所需自动递增值的数量)的语句。比如INSERT ... SELECT
,REPLACE ... SELECT
和LOAD DATA
语句,但不包括纯INSERT。 InnoDB在每处理一行,为AUTO_INCREMENT列分配一个新值。
3. “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-INT锁是当向使用含有AUTO_INCREMENT列的表中插入数据时需要获取的一种特殊的表级锁,在执行插入语句时就在表级别加一个AUTO-INT锁,然后为每条待插入记录的AUTO_INCREMENT修饰的列分配递增的值,在该语句执行结束后,再把AUTO-INT锁释放掉。一个事务在持有AUTO-INC锁的过程中,其他事务的插入语句都要被阻塞,可以保证一个语句中分配的递增值是连续的。也正因为此,其并发性显然并不高,当我们向一个有AUTO_INCREMENT关键字的主键插入值的时候,每条语句都要对这个表锁进行竞争,这样的并发潜力其实是很低下的,所以innodb通过innodb_autoinc_lock_mode
的不同取值来提供不同的锁定机制,来显著提高SQL语句的可伸缩性和性能。
innodb_autoinc_lock_mode有三种取值,分别对应与不同锁定模式:
(1)innodb_autoinc_lock_mode = 0(“传统”锁定模式)
在此锁定模式下,所有类型的insert语句都会获得一个特殊的表级AUTO-INC锁,用于插入具有AUTO_INCREMENT列的表。这种模式其实就如我们上面的例子,即每当执行insert的时候,都会得到一个表级锁(AUTO-INC锁),使得语句中生成的auto_increment为顺序,且在binlog中重放的时候,可以保证master与slave中数据的auto_increment是相同的。因为是表级锁,当在同一时间多个事务中执行insert的时候,对于AUTO-INC锁的争夺会限制并发
能力。
(2)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锁由另一个事务保持。如果另一个事务保持AUTO-INC锁,则“Simple inserts”等待AUTO-INC锁,如同它是一个“bulk inserts”。
(3)innodb_autoinc_lock_mode = 2(“交错”锁定模式)
从 MySQL 8.0 开始,交错锁模式是默认
设置。
在这种锁定模式下,所有类INSERT语句都不会使用表级AUTO-INC锁,并且可以同时执行多个语句。这是最快和最可拓展的锁定模式,但是当使用基于语句的复制或恢复方案时,从二进制日志重播SQL语句时,这是不安全的。
在此锁定模式下,自动递增值保证
在所有并发执行的所有类型的insert语句中是唯一
且单调递增
的。但是,由于多个语句可以同时生成数字(即,跨语句交叉编号),为任何给定语句插入的行生成的值可能不是连续的。
④ 元数据锁(MDL锁)
MySQL5.5引入了meta data lock,简称MDL锁,属于表锁范畴。MDL 的作用是,保证读写的正确性。比如,如果一个查询正在遍历一个表中的数据,而执行期间另一个线程对这个表结构做变更
,增加了一列,那么查询线程拿到的结果跟表结构对不上,肯定是不行的。
因此,当对一个表做增删改查操作的时候,加MDL读锁;当要对表做结构变更操作的时候,加MDL写锁。
2. InnoDB中的行锁
行锁(Row Lock)也称为记录锁,顾名思义,就是锁住某一行(某条记录row)。需要注意的是,MySQL服务器层并没有实现行锁机制,行级锁只在存储引擎层实现。
**优点:**锁定力度小,发生锁冲突概率低
,可以实现的并发度高
**缺点:**对于锁的开销比较大
,加锁会比较慢,容易出现死锁
情况
InnoDB与MyISAM的最大不同有两点:一是支持事务;二是采用了行级锁。
① 记录锁(Record Locks)
记录锁也就是仅仅把一条记录锁上,官方的类型名称为:LOCK_REC_NOT_GAP
。
记录锁是有S锁和X锁之分的,称之为S型记录锁
和X型记录锁
。
- 当一个事务获取了一条记录的S型记录锁后,其他事务也可以继续获取该记录的S型记录锁,但不可以继续获取X型记录锁;
- 当一个事务获取了一条记录的X型记录锁后,其他事务既不可以继续获取该记录的S型记录锁,也不可以继续获取X型记录锁。
② 间隙锁(Gap Locks)
MySQL
在REPEATABLE READ
隔离级别下是可以解决幻读问题的,解决方案有两种,可以使用MVCC
方案解决,也可以采用加锁
方案解决。但是在使用加锁方案解决时有个大问题,就是事务在第一次执行读取操作时,那些幻影记录尚不存在,我们无法给这些幻影记录
加上记录锁
。InnoDB提出了一种称之为Gap Locks
的锁,官方的类型名称为:LOCK_GAP
,我们可以简称为gap锁
。
gap锁的提出仅仅是为了防止插入幻影记录而提出的。虽然有共享gap锁
和独占gap锁
这样的说法,但是它们起到的作用是相同的。而且如果对一条记录加了gap锁(不论是共享gap锁还是独占gap锁),并不会限制其他事务对这条记录加记录锁或者继续加gap锁。
③ 临键锁(Next-Key Locks)
有时候我们既想锁住某条记录
,又想阻止
其他事务在该记录前边的间隙插入新记录
,所以InnoDB就提出了一种称之为Next-Key Locks
的锁,官方的类型名称为:LOCK_ORDINARY
,我们也可以简称为next-key锁
。Next-Key Locks是在存储引擎innodb
、事务级别在可重复读
的情况下使用的数据库锁,innodb默认的锁就是Next-Key locks。
begin;
select * from student where id <=8 and id > 3 for update;
④ 插入意向锁(Insert Intention Locks)
我们说一个事务在插入
一条记录时需要判断一下插入位置是不是被别的事务加了gap锁
(next-key锁
也包含gap锁
),如果有的话,插入操作需要等待,直到拥有gap锁
的那个事务提交。但是InnoDB规定事务在等待的时候也需要在内存中生成一个锁结构,表明有事务想在某个间隙
中插入
新记录,但是现在在等待。InnoDB就把这种类型的锁命名为Insert Intention Locks
,官方的类型名称为:LOCK_INSERT_INTENTION
,我们称为插入意向锁
。插入意向锁是一种Gap锁
,不是意向锁,在insert操作时产生。
插入意向锁是在插入一条记录行前,由INSERT 操作产生的一种间隙锁
。
事实上插入意向锁并不会阻止别的事务继续获取该记录上任何类型的锁。
3. 页锁
页锁就是在页的粒度
上进行锁定,锁定的数据资源比行锁要多,因为一个页中可以有多个行记录。当我们使用页锁的时候,会出现数据浪费的现象,但这样的浪费最多也就是一个页上的数据行。页锁的开销介于表锁和行锁之间,会出现死锁。锁定粒度介于表锁和行锁之间,并发度一般。
每个层级的锁数量是有限制的,因为锁会占用内存空间,锁空间的大小是有限的
。当某个层级的锁数量超过了这个层级的阈值时,就会进行锁升级
。锁升级就是用更大粒度的锁替代多个更小粒度的锁,比如InnoDB 中行锁升级为表锁,这样做的好处是占用的锁空间降低了,但同时数据的并发度也下降了。
3.3 从对待锁的态度划分:乐观锁、悲观锁
从对待锁的态度来看锁的话,可以将锁分成乐观锁和悲观锁,从名字中也可以看出这两种锁是两种看待数据并发的思维方式
。需要注意的是,乐观锁和悲观锁并不是锁,而是锁的设计思想
。
1. 悲观锁(Pessimistic Locking)
悲观锁总是假设最坏的情况,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会阻塞
直到它拿到锁(共享资源每次只给一个线程使用,其它线程阻塞,用完后再把资源转让给其它线程)。比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁,当其他线程想要访问数据时,都需要阻塞挂起。Java中synchronized
和ReentrantLock
等独占锁就是悲观锁思想的实现。
注意:select … for update 语句执行过程中所有扫描的行都会被锁上,因此在MySQL中用悲观锁必须确定使用了索引,而不是全表扫描,否则将会把整个表锁住。
2. 乐观锁(Optimistic Locking)
乐观锁认为对同一数据的并发操作不会总发生,属于小概率事件,不用每次都对数据上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,也就是不采用数据库自身的锁机制,而是通过程序来实现。在程序上,我们可以采用版本号机制
或者CAS机制
实现。乐观锁适用于多读的应用类型,这样可以提高吞吐量。在Java中java.util.concurrent.atomic
包下的原子变量类就是使用了乐观锁的一种实现方式:CAS实现的。
1. 乐观锁的版本号机制
在表中设计一个版本字段 version
,第一次读的时候,会获取 version 字段的取值。然后对数据进行更新或删除操作时,会执行UPDATE ... SET version=version+1 WHERE version=version
。此时如果已经有事务对这条数据进行了更改,修改就不会成功。
2. 乐观锁的时间戳机制
时间戳和版本号机制一样,也是在更新提交的时候,将当前数据的时间戳和更新之前取得的时间戳进行比较,如果两者一致则更新成功,否则就是版本冲突。
你能看到乐观锁就是程序员自己控制数据并发操作的权限,基本是通过给数据行增加一个戳(版本号或者时间戳),从而证明当前拿到的数据是否最新。
3. 两种锁的适用场景
从这两种锁的设计思想中,我们总结一下乐观锁和悲观锁的适用场景:
-
乐观锁
适合读操作多
的场景,相对来说写的操作比较少。它的优点在于程序实现
,不存在死锁
问题,不过适用场景也会相对乐观,因为它阻止不了除了程序以外的数据库操作。 -
悲观锁
适合写操作多
的场景,因为写的操作具有排它性
。采用悲观锁的方式,可以在数据库层面阻止其他事务对该数据的操作权限,防止读 - 写
和写 - 写
的冲突。
3.4 按加锁的方式划分:显式锁、隐式锁
1. 隐式锁
-
**情景一:**对于聚簇索引记录来说,有一个
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锁
时,由于隐式锁
的存在,会先帮助当前事务生成一个锁结构,然后自己再生成一个锁结构后进入等待状态。隐式锁是一种延迟加锁
的机制,从而来减少加锁的数量。
2. 显式锁
通过特定的语句进行加锁,我们一般称之为显示加锁。
3.5 其它锁之:全局锁
全局锁就是对整个数据库实例
加锁。当你需要让整个库处于只读状态
的时候,可以使用这个命令,之后其他线程的以下语句会被阻塞:数据更新语句(数据的增删改)、数据定义语句(包括建表、修改表结构等)和更新类事务的提交语句。全局锁的典型使用场景
是:做全库逻辑备份
。
全局锁的命令:
Flush tables with read lock
3.6 其它锁之:死锁
死锁是指两个或多个事务在同一资源上相互占用,并请求锁定对方占用的资源,从而导致恶性循环。
1. 如何处理死锁
**方式1:**等待,直到超时(innodb_lock_wait_timeout=50s)
即当两个事务互相等待时,当一个事务等待时间超过设置的阈值时,就将其回滚
,另外事务继续进行。
**方式2:**使用死锁检测进行死锁处理
发起死锁检测,发现死锁后,主动回滚死锁链条中的某一个事务(将持有最少行级排他锁的事务进行回滚),让其他事务得以继续执行。
4. 锁的内存结构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ycCBDAro-1656249929132)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204051514736.png)]
结构解析:
1. 锁所在的事务信息
:
不论是表锁
还是行锁
,都是在事务执行过程中生成的,哪个事务生成了这个 锁结构 ,这里就记录这个事务的信息。
此锁所在的事务信息
在内存结构中只是一个指针,通过指针可以找到内存中关于该事务的更多信息,比方说事务id等。
2. 索引信息
:
对于行锁
来说,需要记录一下加锁的记录是属于哪个索引的。这里也是一个指针。
3. 表锁/行锁信息
:
表锁结构
和行锁结构
在这个位置的内容是不同的:
- 表锁:记载着是对哪个表加的锁,还有其他的一些信息。
- 行锁:记载了三个重要的信息:
- Space ID :记录所在表空间。
- Page Number :记录所在页号。
- n_bits :对于行锁来说,一条记录就对应着一个比特位,一个页面中包含很多记录,用不同的比特位来区分到底是哪一条记录加了锁。为此在行锁结构的末尾放置了一堆比特位,这个n_bits 属性代表使用了多少比特位。
n_bits的值一般都比页面中记录条数多一些。主要是为了之后在页面中插入了新记录后也不至于重新分配锁结构
4. type_mode
:
这是一个32位的数,被分成了lock_mode
、lock_type
和rec_lock_type
三个部分,如图所示:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-D3h4vBpE-1656249929133)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204051518659.png)]
- 锁的模式(
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
属性呢?基于内存空间的节省,所以把 is_waiting 属性放到了 type_mode 这个32位的数字中:LOCK_WAIT
(十进制的256
) :当第9个比特位置为1
时,表示is_waiting
为true
,也就是当前事务尚未获取到锁,处在等待状态;当这个比特位为0
时,表示is_waiting
为false
,也就是当前事务获取锁成功。
5. 其他信息
:
为了更好的管理系统运行过程中生成的各种锁结构而设计了各种哈希表和链表。
6. 一堆比特位
:
如果是行锁结构
的话,在该结构末尾还放置了一堆比特位,比特位的数量是由上边提到的n_bits
属性表示的。InnoDB数据页中的每条记录在记录头信息
中都包含一个 heap_no 属性,伪记录Infimum
的heap_no
值为0
,Supremum
的heap_no
值为1
,之后每插入一条记录,heap_no
值就增1。锁结构
最后的一堆比特位就对应着一个页面中的记录,一个比特位映射一个heap_no
,即一个比特位映射到页内的一条记录。
5. 锁监控
mysql> show status like 'innodb_row_lock%';
- Innodb_row_lock_current_waits:当前正在等待锁定的数量;
Innodb_row_lock_time
:从系统启动到现在锁定总时间长度;(等待总时长)Innodb_row_lock_time_avg
:每次等待所花平均时间;(等待平均时长)- Innodb_row_lock_time_max:从系统启动到现在等待最常的一次所花的时间;
Innodb_row_lock_waits
:系统启动后到现在总共等待的次数;(等待总次数)
其他监控方法:
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
所代替。