目录
讲解一:基本先容
一、简介
二、MySQL中的锁
1. 锁粒度分类(三类)
讲解二:全局锁\表级锁\行锁
一、全局锁
1. 简介
2. 不加全局锁的题目
3. 加全局锁的好处
4. 操作
加全局锁
数据备份
释放锁
5. 特点
二、表级锁
1. 简介
2. 表级锁分类(三类)
三、表锁分类(两类)
1. 简介
2. 两类
3. 语法
加锁
释放锁
4. 特点
读锁
写锁
结论
四、元数据锁分类(两类)
1. 简介
2. 演示
五、意向锁(两类)
1. 简介
2. 分类
2.1. 意向共享锁(IS)
2.2. 意向排他锁(IX)
3. 演示
3.1. 意向共享锁与表读锁是兼容的
3.2. 意向排他锁与表读锁、写锁都是互斥的
六、行级锁(三类)
1. 简介
2. 行级锁分类(三类)
2.1. 行锁(Record Lock)
2.2. 间隙锁(Gap Lock)
2.3. 临键锁(Next-Key Lock)
七、行锁(两类)
1. 简介
2. 两种行锁的兼容情况
3. 常见SQL语句实行时所加行锁
4. 演示
4.1. 数据准备
4.2. 平凡的select语句,实行时,不会加锁
4.3. 加共享锁,共享锁与共享锁之间兼容
4.4. 共享锁与排他锁之间互斥
4.5. 排它锁与排他锁之间互斥
4.6. 无索引行锁升级为表锁
八、间隙锁&临键锁
1. 简介
2. 示例演示
2.1. 简介
2.2. 分析
讲解三:灰心锁\乐观锁
一、灰心锁(Pessimistic Lock)
1. 简介
2. 实现方式
3. 优缺点
二、乐观锁(Optimistic Lock)
1. 简介
2. 实现方式
3. 优缺点
讲解一:基本先容
一、简介
锁是盘算机和谐多个进程或线程并发访问某一资源的机制。
在数据库中,除传统的盘算资源(CPU、RAM、I/O)的争用以外,
数据也是一种供很多用户共享的资源。
如何保证数据并发访问的划一性、有用性是全部数据库必须解决的一个题目,锁冲突也是影响数据库并
发访问性能的一个重要因素。
从这个角度来说,锁对数据库而言显得尤其重要,也更加复杂。
二、MySQL中的锁
1. 锁粒度分类(三类)
MySQL中的锁,按照锁的粒度分,分为以下三类:
表级锁是MySQL中锁定粒度最大的一种锁,表现对当前操作的整张表加锁,它实现简单,资源消耗较
少,被大部分MySQL引擎支持。
最常使用的MYISAM与INNODB都支持表级锁定
开销小,加锁快;不会出现死锁;锁定粒度大,发出锁冲突的概率最高,并发度最低。
行级锁是Mysql中锁定粒度最细的一种锁,表现只针对当前操作的行进行加锁。
行级锁能大大减少数据库操作的冲突。
其加锁粒度最小,但加锁的开销也最大。
行级锁分为共享锁和排他锁
开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。
常见存储引擎支持的锁
- InnoDB支持行级锁(row-level locking)和表级锁,默以为行级锁。
- MyISAM接纳表级锁(table-level locking)
只有通过索引条件检索数据,才会使用行锁, 否则使用的是表锁。
详细先容: - 全局锁\表级锁\行锁
讲解二:全局锁\表级锁\行锁
一、全局锁
1. 简介
全局锁就是对整个数据库实例加锁,加锁后整个实例就处于只读状态,
后续的DML的写语句,DDL语句,已经更新操作的事务提交语句都将被阻塞。
其典范的使用场景是做全库的逻辑备份,对全部的表进行锁定,从而获取划一性视图,保证数据的完备性。
题目:为什么全库逻辑备份,就需要加全就锁呢?
2. 不加全局锁的题目
我们一起先来分析一下不加全局锁,大概存在的题目
假设在数据库中存在这样三张表: tb_stock 库存表,tb_order 订单表,tb_orderlog 订单日记表。
- 在进行数据备份时,先备份了tb_stock库存表。
- 然后接下来,在业务系统中,实行了下单操作,扣减库存,生成订单
(更新tb_stock表,插入tb_order表)。
- 然后再实行备份 tb_order表的逻辑。
- 业务中实行插入订单日记操作。
- 末了,又备份了tb_orderlog表。
此时备份出来的数据,是存在题目的。
因为备份出来的数据,tb_stock表与tb_order表的数据不划一(有最新操作的订单信息,但是库存数没减)。
那如何来规避这种题目呢?此时就可以借助于MySQL的全局锁来解决。
3. 加全局锁的好处
再来分析一下加了全局锁后的情况
对数据库进行进行逻辑备份之前,先对整个数据库加上全局锁,一旦加了全局锁之后,其他的DDL、DML全部
都处于阻塞状态,但是可以实行DQL语句,也就是处于只读状态,而数据备份就是查询操作。
那么数据在进行逻辑备份的过程中,数据库中的数据就是不会发生变革的,
这样就保证了数据的划一性和完备性。
4. 操作
加全局锁
- flush tables with read lock ;
复制代码 数据备份
- mysqldump -uroot –p1234 zhenge > zhenge.sql
复制代码 数据备份的相关指令, 在后面MySQL管理部分详细先容.
释放锁
5. 特点
数据库中加全局锁,是一个比力重的操作,存在以下题目:
① 如果在主库上备份,那么在备份期间都不能实行更新,业务基本上就得停摆。
② 如果在从库上备份,那么在备份期间从库不能实行主库同步过来的二进制日记(binlog),
会导致主从延迟。
在InnoDB引擎中,我们可以在备份时加上参数 --single-transaction 参数来完成不加锁的划一性数据备份。
- mysqldump --single-transaction -uroot –p123456 zhenge > zhenge.sql
复制代码 二、表级锁
1. 简介
表级锁,每次操作锁住整张表。锁定粒度大,发生锁冲突的概率最高,并发度最低。
应用在MyISAM、InnoDB、BDB等存储引擎中。
2. 表级锁分类(三类)
对于表级锁,重要分为以下三类:
表锁、元数据锁(meta data lock,MDL)、意向锁
三、表锁分类(两类)
1. 简介
2. 两类
对于表锁,又分为两类:
- 表共享读锁(read lock)
- 表独占写锁(write lock)
3. 语法
加锁
- lock tables 表名... read/write
复制代码 释放锁
4. 特点
读锁
左侧为客户端一,对指定表加了读锁,不会影响右侧客户端二的读,但是会阻塞右侧客户端的写。
测试:
写锁
左侧为客户端一,对指定表加了写锁,会阻塞右侧客户端的读和写。
测试:
结论
读锁不会阻塞其他客户端的读,但是会阻塞写。写锁既会阻塞其他客户端的读,又会阻塞其他客户端的写。
四、元数据锁分类(两类)
1. 简介
meta data lock , 元数据锁,简写MDL。
MDL加锁过程是系统自动控制,无需显式使用,在访问一张表的时间会自动加上。
MDL锁重要作用是维护表元数据的数据划一性,在表上有活动事务的时间,不可以对元数据进行写入操作。
为了避免DML与DDL冲突,保证读写的正确性
这里的元数据,大家可以简单明白为就是一张表的表结构。
也就是说,某一张表涉及到未提交的事务时,是不能够修改这张表的表结构的。
在MySQL5.5中引入了MDL,当对一张表进行增编削查的时间,加MDL读锁(共享);
当对表结构进行变动操作的时间,加MDL写锁(排他)
常见的SQL操作时,所添加的元数据锁:
锁类型
| 对应SQL
| 阐明
| SHARED_READ_ONLY / SHARED_NO_READ_WRITE
| lock tables xxx read / write
|
| SHARED_READ
| select 、select ... lock in share mode
| 与SHARED_READ、SHARED_WRITE兼容,与EXCLUSIVE互斥
| SHARED_WRITE
| insert 、update、delete、select ... for update
| 与SHARED_READ、SHARED_WRITE兼容,与EXCLUSIVE互斥
| EXCLUSIVE
| alter table ...
| 与其他的MDL都互斥
| 2. 演示
当实行SELECT、INSERT、UPDATE、DELETE等语句时,添加的是元数据共享锁
(SHARED_READ / SHARED_WRITE),之间是兼容的。
当实行SELECT语句时,添加的是元数据共享锁(SHARED_READ),会阻塞元数据排他锁(EXCLUSIVE),
之间是互斥的。
我们可以通过下面的SQL,来查看数据库中的元数据锁的情况:
- select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema.metadata_locks;
复制代码 我们在操作过程中,可以通过上述的SQL语句,来查看元数据锁的加锁情况。
五、意向锁(两类)
1. 简介
为了避免DML在实行时,加的行锁与表锁的冲突,在InnoDB中引入了意向锁,使得表锁不用检查每行数据是
否加锁,使用意向锁来减少表锁的检查。
如果没有意向锁,客户端一对表加了行锁后,客户端二如何给表加表锁呢,来通过表现图简单分析一下:
首先客户端一,开启一个事务,然后实行DML操作,在实行DML语句时,会对涉及到的行加行锁。
当客户端二,想对这张表加表锁时,会检查当前表是否有对应的行锁,如果没有,则添加表锁,
此时就会从第一行数据,检查到末了一行数据,效率较低。
有了意向锁之后 :
客户端一,在实行DML操作时,会对涉及的行加行锁,同时也会对该表加上意向锁。
而其他客户端,在对这张表加表锁的时间,会根据该表上所加的意向锁来判定是否可以乐成加表锁,而不用逐
行判断行锁情况了。
2. 分类
2.1. 意向共享锁(IS)
由语句select ... lock in share mode添加 。与 表锁共享锁(read)兼容,与表锁排他锁(write)互斥。
2.2. 意向排他锁(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;
复制代码 3. 演示
3.1. 意向共享锁与表读锁是兼容的
3.2. 意向排他锁与表读锁、写锁都是互斥的
六、行级锁(三类)
1. 简介
行级锁,每次操作锁住对应的行数据。锁定粒度最小,发生锁冲突的概率最低,并发度最高。
应用在InnoDB存储引擎中。
InnoDB的数据是基于索引构造的,行锁是通过对索引上的索引项加锁来实现的,而不是对纪录加的锁。
2. 行级锁分类(三类)
对于行级锁,重要分为以下三类
2.1. 行锁(Record Lock)
行锁:锁定单个行纪录的锁,防止其他事务对此行进行update和delete。在RC、RR隔离级别下都支持。
2.2. 间隙锁(Gap Lock)
间隙锁:锁定索引纪录间隙(不含该纪录),确保索引纪录间隙稳定,防止其他事务在这个间隙进行insert,
产生幻读。在RR隔离级别下都支持。
2.3. 临键锁(Next-Key Lock)
临键锁:行锁和间隙锁组合,同时锁住数据,并锁住数据前面的间隙Gap。在RR隔离级别下支持。
七、行锁(两类)
1. 简介
InnoDB实现了以下两种类型的行锁:
① 共享锁(S):允许一个事务去读一行,制止其他事务得到相同数据集的排它锁。
② 排他锁(X):允许获取排他锁的事务更新数据,制止其他事务得到相同数据集的共享锁和排他锁。
2. 两种行锁的兼容情况
3. 常见SQL语句实行时所加行锁
SQL
| 行锁类型
| 阐明
| INSERT ...
| 排他锁
| 自动加锁
| UPDATE ...
| 排他锁
| 自动加锁
| DELETE ...
| 排他锁
| 自动加锁
| SELECT(正常)
| 不加任何 锁
|
| SELECT ... LOCK IN SHARE MODE
| 共享锁
| 需要手动在SELECT之后加LOCK IN SHARE MODE
| SELECT ... FOR UPDATE
| 排他锁
| 需要手动在SELECT之后加FOR UPDATE
| 4. 演示
默认情况下,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;
复制代码 4.1. 数据准备
- DROP TABLE IF EXISTS stu;
- CREATE TABLE stu (
- id int NOT NULL AUTO_INCREMENT,
- age int NOT NULL,
- name varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,
- PRIMARY KEY (id) USING BTREE,
- INDEX idx_t_age(age) USING BTREE
- ) ENGINE = InnoDB CHARACTER SET = utf8mb4;
- INSERT INTO stu VALUES (1, 1, 'tom');
- INSERT INTO stu VALUES (3, 3, 'cat');
- INSERT INTO stu VALUES (8, 8, 'rose');
- INSERT INTO stu VALUES (11, 11, 'jetty');
- INSERT INTO stu VALUES (19, 19, 'lily');
- INSERT INTO stu VALUES (25, 25, 'luci');
复制代码 演示行锁的时间,我们就通过上面这张表来演示一下。
4.2. 平凡的select语句,实行时,不会加锁
4.3. 加共享锁,共享锁与共享锁之间兼容
select...lock in share mode,加共享锁,共享锁与共享锁之间兼容
4.4. 共享锁与排他锁之间互斥
客户端一获取的是id为1这行的共享锁,客户端二是可以获取id为3这行的排它锁的,因为不是同一行数据。
而如果客户端二想获取id为1这行的排他锁,会处于阻塞状态,以为共享锁与排他锁之间互斥。
4.5. 排它锁与排他锁之间互斥
当客户端一,实行update语句,会为id为1的纪录加排他锁;
客户端二,如果也实行update语句更新id为1的数据,也要为id为1的数据加排他锁,
但是客户端二会处于阻塞状态,因为排他锁之间是互斥的。
直到客户端一,把事务提交了,才会把这一行的行锁释放,此时客户端二,解除阻塞。
4.6. 无索引行锁升级为表锁
stu表中数据如下:
我们在两个客户端中实行如下操作:
在客户端一中,开启事务,并实行update语句,更新name为Lily的数据,也就是id为19的纪录 。
然后在客户端二中更新id为3的纪录,却不能直接实行,会处于阻塞状态,为什么呢?
缘故起因就是因为此时,客户端一,根据name字段进行更新时,name字段是没有索引的,
如果没有索引,此时行锁会升级为表锁(因为行锁是对索引项加的锁,而name没有索引)。
接下来,我们再针对name字段建立索引,索引建立之后,再次做一个测试:
此时我们可以看到,客户端一,开启事务,然后依然是根据name进行更新。
而客户端二,在更新id为3的数据时,更新乐成,并未进入阻塞状态。
这样就阐明,我们根据索引字段进行更新操作,就可以避免行锁升级为表锁的情况。
八、间隙锁&临键锁
1. 简介
默认情况下,InnoDB在 REPEATABLE READ事务隔离级别运行,
InnoDB使用 next-key 锁进行搜索和索引扫描,以防止幻读。
① 索引上的等值查询(唯一索引),给不存在的纪录加锁时, 优化为间隙锁 。
② 索引上的等值查询(非唯一平凡索引),向右遍历时末了一个值不满足查询需求时,next-key lock 退化为间
隙锁。
③ 索引上的范围查询(唯一索引)--会访问到不满足条件的第一个值为止。
留意:
间隙锁唯一目标是防止其他事务插入间隙。
间隙锁可以共存,一个事务接纳的间隙锁不会制止另一个事务在同一间隙上接纳间隙锁。
2. 示例演示
2.1. 简介
- 索引上的等值查询(唯一索引),给不存在的纪录加锁时, 优化为间隙锁 。
- 索引上的等值查询(非唯一平凡索引),向右遍历时末了一个值不满足查询需求时,
next-key lock 退化为间隙锁。
2.2. 分析
我们知道InnoDB的B+树索引,叶子节点是有序的双向链表。
如果,我们要根据这个二级索引查询值为18的数据,并加上共享锁,我们是只锁定18这一行就可以了吗?
并不是,因为是非唯一索引,这个结构中大概有多个18的存在,
所以,在加锁时会继续以后找,找到一个不满足条件的值(当前案例中也就是29)。
此时会对18加临键锁,并对29之前的间隙加锁。
索引上的范围查询(唯一索引)--会访问到不满足条件的第一个值为止。
查询的条件为id>=19,并添加共享锁。 此时我们可以根据数据库表中现有的数据,将数据分为三个部分:
所以数据库数据在加锁是,就是将19加了行锁,25的临键锁(包罗25及25之前的间隙),正无穷的临键锁
(正无穷及之前的间隙)。
讲解三:灰心锁\乐观锁
一、灰心锁(Pessimistic Lock)
1. 简介
灰心锁,顾名思义,就是很灰心,每次去拿数据的时间都以为别人会修改,所以每次在拿数据的时间都会上
锁,这样别人想拿这个数据就会 block 直到它拿到锁。
传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先
上锁。
2. 实现方式
灰心锁的简单实现方式
如:A 和 B 两个人同时实行下面的 SQL:
- select * from student where id = 1 for update;
复制代码 当 A 在实行,还未提交当前事务,此时 B 不能实行该 SQL,处于阻塞状态。
3. 优缺点
长处:安全,在实行大量的修改数据操作的时间使用
缺点:效率较低,如果操作中查询居多,修改较少的情况,不发起使用灰心锁。
二、乐观锁(Optimistic Lock)
1. 简介
乐观锁,顾名思义,就是很乐观,每次去拿数据的时间都以为别人不会修改,所以不会上锁,
但是在更新的时间会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。
乐观锁实用于多读的应用类型,这样可以进步吞吐量,像数据库如果提供类似于 write_condition 机制的其实
都是提供的乐观锁。
2. 实现方式
在表中添加一个 int 类型的列:version
在实行修改之前,先将当前数据的 version 查询出来:
- select version from student where id = 1
复制代码 然后在修改的时间,在条件中增加 version:
- update student set name = 'lucy' , version = version + 1 where id = 1 and version = 1
复制代码 此时,若另一个并发的事务同时修改这条数据的时间,实行的SQL:
- update student set name = 'lily', version = version + 1 where id = 1 and version = 1
复制代码 因为前一个事务已经将 version 修改为 2,
所以这条 SQL 实行返回的受影响的行数为 0(表现修改失败),给用户相应的提示信息即可。
3. 优缺点
长处:相对于灰心所而言,乐观锁实行的效率更高。
缺点:当实行大量的修改操作的时间,会常常出现修改失败的情况,用户体验不好。发起在实行查询多,修改
少的时间使用。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。 |