文章目录
- 锁
- 0、概述
- 一、全局锁
- 1.1 概述
- 1.2 语法
- 1.3 一致性数据备份
- 1.4 问题
- 二、表级锁
- 2.1 表锁
- 2.2 元数据锁
- 2.3 意向锁
- 三、行级锁
- 3.1 概述
- 3.2 行锁
- 3.3 间隙锁 与 临建锁
锁
0、概述
锁是计算机协调多个进程和线程并发访问某一资源的机制。
在数据库中,除传统的计算资源(CPU、RAM、I/O)的挣用以外,数据也是一种供许多用户共享的资源。
如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题,锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说,锁对数据库而言显得尤其重要,也更加复杂。
分类
- 全局锁:锁定数据库中的所有表
- 表级锁:每次操作锁住整张表
- 行级锁:每次操作锁住对应的行数据。
一、全局锁
1.1 概述
全局锁:锁定数据库中的所有表
全局锁就是对整个数据库实例加锁,加锁后整个实例就处于只读状态,后续的DML写语句,DDL语句,已经更新操作的数据提交语句都将被阻塞(但是可以查询)。
典型的使用场景是做全库的逻辑备份,对所有的表进行锁定,从而获取一致性视图,保证数据完整性。
备份完成后生成xxx.sql,全局锁会打开
如果我们在全库备份的时候不锁住会怎么样?
在备份的时候业务系统还不断地在往数据库中操作数据,此时会产生一种现象:数据不一致。
比如说我们已经将库存表进行了备份(但还没有备份订单表等其他表),但是仍有业务操作库存表,使得库存表数据改变,那此时备份的数据又与实际的不符合了。
1.2 语法
- 加全局锁
flush tables with read lock ;
-
数据备份
mysqldump:是数据库给我们提供的数据备份工具
-uroot –proo :有用户名和密码
itcast: 要备份的数据库的名字
itcast.sql:备份到那个SQL文件
mysqldump -uroot –proot itcast > itcast.sql
如果连接的远程数据库,需要在-u前面添加 -h远程主机地址
- 释放锁
unlock tables ;
1.3 一致性数据备份
添加全局锁
添加全局锁之后,其他客户端只能读,不能写
flush tables with read lock ;
数据备份
mysqldump 是MySQL提供的工具,如果是窗口命令行的形式,不要在MySQL的命令行中运行,直接在Window下运行即可
mysqldump -uroot –proot itcast > D:\itcast.sql
在磁盘对应位置找到对应的文件,成功备份
1.4 问题
数据库中加全局锁,存在以下问题:
- 如果在主库上备份,那么在备份期间都不能执行更新,业务基本上就得停摆。
- 如果在从库上备份,那么在备份期间从库不能执行主库同步过来的二进制日志(binlog),会导致主从延迟。
在InnoDB引擎中,我们可以在备份时加上参数 --single-transaction 参数来完成不加锁的一致性数据备份。
--single-transaction: 快照读
mysqldump --single-transaction -uroot –p123456 itcast > itcast.sql
二、表级锁
表级锁:每次操作锁住整张表
锁定粒度大,发生锁冲突的概率最高,并发度最低。应用在MyISAM、InnoDB、BDB等存储引擎中。
三类
-
表锁
-
- 表共享读锁(read lock),即读锁
- 表独占写锁(write lock),即写锁
-
元数据锁(meta data lock , MDL)
-
意向锁
2.1 表锁
表锁分为两类
-
表共享读锁(read lock),即读锁
加了读锁后,只能读,对于其他客户端也想通,只能读不能写
-
表独占写锁(write lock),即写锁
当添加写锁后,本客户端既能读,又能写,其他客户端不能读也不能写
语法
- 加锁
lock tables 表名... read/write
- 释放锁
unlock tables / 客户端断开连接
2.2 元数据锁
元数据锁加锁过程是系统自动控制的,无需显示使用,在访问一张表的时候会自动加上。
元数据锁的主要作用是维护表元数据的数据一致性,在表上有活动事务的时候,不可以对元数据进行写入操作。
查看元数据锁
select object_type,object_schema,object_name,lock_type,lock_duration
from performance_schema.metadata_locks ;
元数据可以简单的理解为表结构。如果某一张表存在未提交的事务,我们不能去修改这张表结构。
避免了DML(增删改)与DDL(对数据库表的操作)冲突,保证读写的正确性。
在MySQL5.5中引入了MDL,当对一张表进行增删改查的时候,加MDL读锁(共享);当对表结构进行飙风操作的时候,加MDL写锁(排他)
读锁之间是可以兼容的,但是写锁之间以及写锁和读锁之间是互斥的
SHARED_READ、SHARED_WRITE是兼容的,但是他们与EXCLUSIVE是互斥的
对应SQL | 锁类型 | 说明 |
---|---|---|
lock tables xxx read / write | SHARED_READ_ONLY / SHARED_NO_READ_WRITE | |
select 、select … lock in share mode | SHARED_READ | 与SHARED_READ、SHARED_WRITE兼容,与EXCLUSIVE互斥 |
insert 、update、delete、select … for update | SHARED_WRITE | 与SHARED_READ、SHARED_WRITE兼容,与EXCLUSIVE互斥 |
alter table … | EXCLUSIVE(排他锁) | 与其他的MDL都互斥 |
当执行SELECT、INSERT、UPDATE、DELETE等语句时,添加的是元数据共享锁(SHARED_READ /SHARED_WRITE),之间是兼容的。
假设A开启事务,执行了select语句,此时为表增加了一个共享锁,注意此时未提交事务;
此时B开启事务,修改表结构,我们回车后并没有动静,并且此时表增加了一个排他锁,
B进入了堵塞,因为共享锁和排他锁是不能兼容的,B执行的晚,则B进入堵塞状态,一直堵塞到A提交事务。
2.3 意向锁
为了避免DML在执行时,加的行锁与表锁的冲突,在InnoDB引入了意向锁,使得表锁不用检查每行数据是否加锁,使用意向锁来减少表锁的检查。
两类:
- 意向共享锁(IS):由语句Select…lock in share mode 添加
与 表锁共享锁(read)兼容,与表锁排他锁(write)互斥。
- 意向排他锁(IX): 由insert、update、delete、Select…for update 添加
与表锁共享锁(read)及排他锁(write)都互斥,意向锁之间不会互斥。
可以通过以下SQL,查看意向锁及行锁的加锁情况:
select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from performance_schema.data_locks;
假如没有意向锁客户端一对表加了行锁后,客户端二如何给表加表锁呢?
- 首先客户端一,开启一个事务,然后执行DML操作,在执行DML语句时,会对涉及到的行加行锁。
- 当客户端二,想对这张表加表锁时,会检查当前表是否有对应的行锁,如果没有,则添加表锁,此时就会从第一行数据,检查到最后一行数据,效率较低
有了意向锁之后
- 客户端一,在执行DML操作时,会对涉及的行加行锁,同时也会对该表加上意向锁。
- 而其他客户端,在对这张表加表锁的时候,会根据该表上所加的意向锁来判定是否可以成功加表锁,而不用逐行判断行锁情况了
三、行级锁
3.1 概述
行级锁,每次操作锁住对应的行数据。
锁定粒度最小,发生锁冲突的概率最低,并发度最高。应用在InnoDB存储引擎中。
InnoDB的数据是基于索引组织的,行锁是通过对索引上的索引项加锁来实现的,而不是对记录加的锁。
这篇文章有对索引的基本结构有所介绍:MySQL——存储引擎与索引应用
InnoDB存储引擎当中索引结构分为聚集所以与二级索引。聚集索引叶子结点挂载的是一行数据,二级索引叶子结点挂载的主键值
对于行级锁,主要分为以下三类:
- 行锁(Record Lock)
锁定单个行记录的锁,防止其他事务对此行进行update和delete。
在RC(read commit)、RR(repeatable read)隔离级别下都支持。
- 间隙锁(Gap Lock)
锁定索引记录间隙(不含该记录),确保索引记录间隙不变,防止其他事务在这个间隙进行insert,产生幻读。在RR隔离级别下都支持。
间隙锁只锁住间隙,不锁住记录
6-12之间有间隙,12-16之间有间隙,16-18之间有间隙…
- 临键锁(Next-Key Lock)
行锁和间隙锁组合,同时锁住数据,并锁住数据前面的间隙Gap。
在RR隔离级别下支持。
3.2 行锁
InnoDB实现了以下两种类型的行锁
- 共享锁(S)
允许一个事务去读一行,阻止其他事物获得相同数据集的排它锁
即共享锁和共享锁之间是兼容的,但是共享锁和排他锁是互斥的
-
排他锁(X)
允许获取排他锁的事务更新数据,阻止其他事务获得相同数据集的共享锁和排他锁。
即假如事务A获取了某一行数据的排他锁,那其他事务就不能再获取这一行数据的共享所及排他锁。
常见的SQL语句对应的行锁
SQL | 行锁类型 | 说明 |
---|---|---|
INSERT … | 排他锁 | 自动加锁 |
UPDATE … | 排他锁 | 自动加锁 |
DELETE | 排他锁 | 自动加锁 |
SELECT(正常) | 不加任何锁 | |
SELECT … LOCK IN SHARE MODE | 共享锁 | 需要手动在SELECT之后加LOCK IN SHARE MODE |
SELECT … FOR UPDATE | 排他锁 | 需要手动在SELECT之后加FOR UPDATE |
默认情况下,InnoDB在 REPEATABLE READ事务隔离级别运行,InnoDB使用 next-key 锁进行搜索和索引扫描,以防止幻读。
针对唯一索引进行检索时,对已存在的记录进行等值匹配时,将会自动优化为行锁
InnoDB的行锁是针对于索引加的锁,不通过索引条件检索数据,那么InnoDB将对表中的所有记录加锁,此时 就会升级为表锁。
可以通过下面的SQL,查看意向锁及行锁的加锁情况
select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from performance_schema.data_locks;
3.3 间隙锁 与 临建锁
默认情况下,InnoDB在 REPEATABLE READ事务隔离级别运行,InnoDB使用 next-key 锁进行搜索和索引扫描,以防止幻读。
-
索引上的等值查询(唯一索引),给不存在的记录加锁时, 优化为间隙锁 。
我们在stu表中有下面几条数据
然后更新一条不存在的数据,上面没有id为5的数据。
update stu set age=10 where id=5;
此时会在id为3与8之间的间隙(不包含3和8的数据 )添加一个间隙锁,并且此时如果我们插入一条id在3-8之间数据,不会插入成功的
- 索引上的等值查询(普通索引,如普通二级索引),向右遍历时最后一个值不满足查询需求时,next-key lock 退化为间隙锁。
B+树索引,叶子节点是有序的双向链表。
根据这个二级索引查询值为18的数据,并加上共享锁,但是不是锁住i为18的这一条数据,因为是普通索引并不是唯一的,可能其他位置还存在18的数据,所以,在加锁时会继续往后找,找到29,不满足为18的条件,所以会对18-29之间的间隙添加间隙锁,18数据之前的间隙也添加间隙锁,为18的数据添加临键锁
- 索引上的范围查询(唯一索引)–会访问到不满足条件的第一个值为止。
会创建临键锁。
select * from stu where id>=19 lock in share mode;
查询的条件为id>=19,并添加共享锁。 此时我们可以根据数据库表中现有的数据,将数据分为三个部分:[19]、(19,25]、(25,+∞]
所以数据库数据在加锁是,就是将19加了行锁,25的临键锁(包含25及25之前的间隙),正无穷的临键锁(正无穷及之前的间隙)。
注意:间隙锁唯一目的是防止其他事务插入间隙。间隙锁可以共存,一个事务采用的间隙锁不会阻止另一个事务在同一间隙上采用间隙锁。