麒麟v10 上部署 TiDB v5.1.2 生产环境优化实践
652
2023-05-27
一篇带给你MySQL锁机制
无论什么时候,只要存在多个连接在同一时刻修改数据,都会涉及到并发控制的问题。MySQL实现了两个层面的并发控制:服务层和引擎层。
锁分类
按照使用场景分类
共享锁:共享锁(shared lock)也称为读锁(read lock)。共享锁是共享的,或者说是相互不阻塞的。多个连接在同一时刻可以同时读取同一个资源,而不相互干扰。
排他锁:排他锁(exclusive lock)也称为写锁(write lock)。写锁是排他的,也就是一个写锁会阻塞其他的写锁和读锁。
按照加锁思想分类
悲观锁:对数据被外界修改保持悲观的态度,在整个数据处理过程中,数据都处于锁定状态。
乐观锁:它认为数据一般情况下不会造成冲突,在数据更新的时候才会对数据的冲突与否进行校验。
按照锁粒度分类
全局锁:对整个数据库实例加锁,它将整个数据库实例处于只读的状态。
表级锁:对整个表进行加锁的方式。MySQL表级锁分为表锁和元数据锁。
行级锁:行锁可以最大程度的支持并发处理,行锁是存储引擎层实现的,而MySQL服务层并没有实现行锁。InnoDB存储引擎行级锁类型:Record Lock、Gap Lock、Next-key Lock。
读写锁
读锁
共享锁:共享锁(shared lock)也称为读锁(read lock)。共享锁是共享的,或者说是相互不阻塞的。多个连接在同一时刻可以同时读取同一个资源,而不相互干扰。
加锁命令
select ...... lock in share mode;
测试
测试时,大家开启两个窗口,建立两个连接,窗口1和窗口2分别对应事务A和事务B。
窗口1:查询id=6的行数据并添加读锁,正确返回数据。窗口2:依然查询id=6的行数据并添加读锁,正确返回数据。读读不冲突。窗口1:对id=6的行执行写操作(update语句),在窗口2的事务提交之前,写操作阻塞,并可能会超时退出。
如果写锁等待时间过长,则会超时退出。
窗口1 mysql> update user set age = 20 where id =6; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
如果在窗口1中的事务在执行写操作等待期间,窗口2的事务也执行同一行数据的写操作,则会导致死锁错误。
窗口2 mysql> update user set age = 30 where id =6; ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
写锁
排他锁(exclusive lock)也称为写锁(write lock)。写锁是排他的,也就是一个写锁会阻塞其他的写锁和读锁。
加锁命令
select ...... for update;
测试
窗口1:查询id=6的行数据并添加写锁,正确返回数据。窗口2:依然查询id=6的行数据并添加写锁,阻塞。写写冲突。窗口1:对id=6的行执行写操作(update语句),写操作未阻塞。窗口1事务提交之后,窗口2的查询语句返回结果。
悲观锁和乐观锁
不论是乐观锁还是悲观锁都是人们定义的一种概念,并不是一种锁实现,它是一种思想。乐观锁比较适用于读多写少的场景,悲观锁适用于写多读少的场景。
悲观锁
当我们对数据库的某一条数据进行修改操作时,为了避免同时有其他人对同一行数据进行修改,通过对数据进行加锁的方式以防止并发问题。这种借助了数据库的锁机制,在修改数据之前先锁定再修改的方式称为悲观锁(Pessimistic Lock)。
悲观锁具有强烈的独占性和排他性,在整个数据的写操作过程,都将数据处于锁定状态。悲观锁的实现往往需要数据库提供的锁机制。
悲观锁的实现:
数据库的锁机制如行锁、表锁、读锁和写锁都是在操作之前先加锁的操作,都属于悲观锁。Java中学习的synchronized关键字也是悲观锁。
乐观锁
乐观锁是相对于悲观锁的概念,乐观锁是假设数据一般情况下都不会存在并发冲突,在数据进行更新的时候才会对数据的冲突与否进行验证。如果存在冲突,则告诉用户结果,由用户决定下一步该怎么做。
乐观锁是一种宽松的加锁方式,它不需要使用数据库本身的锁机制。
乐观锁的实现:
MVCC,数据库多版本控制利用版本号控制数据更新的并发问题,是乐观锁的实现。CAS,比较并交换是Java中乐观锁的实现。
全局锁
全局锁:对整个数据库实例加锁,它将整个数据库实例处于只读的状态。
加锁命令 (FTWRL)
Flush tables with read lock;
应用场景
全局锁常用来对整个数据库实例进行逻辑备份。
全局锁加锁期间,业务的数据更新操作(DML)和 表结构的修改操作(DDL)都是会被锁住的。
此时你是不是有个疑问:开发中备份都是直接使用mysqldump,什么时候使用FTWRL呢?
官方自带的逻辑备份工具mysqldump 使用参数-single -transaction的时候,在导出数据的时候就会启动一个事务,来确保拿到一致性视图,在学习事务隔离的时候我们了解到,基于MVCC的一致性视图,这个过程中的数据是可以正常更新的。但是我们要知道事务是引擎层的实现,并不是每个存储引擎都支持事务。我们在开发中大部分的备份使用的是mysqldump,主要是因为我们的存储引擎大部分情况都是使用的默认的引擎InnoDB。
表级锁
表级锁:即是对整张表进行加锁。表的定义包含两个部分:数据和结构,所以表级锁也分为两类:表锁和元空间锁。
表锁
表锁是MySQL中最基本的锁策略,并且也是开销最小的策略。表锁会锁住整张表,在对表进行写操作(插入、删除、更新等)前,需要先获取写锁,它会阻塞其他用户对该表的所有读写操作。只有没有写锁时,其他读取的用户才能获取读锁。读锁之前互相不会造成阻塞。
写锁的优先级高于读锁,因此一个写锁的请求可能会被插入到读锁队列前面,但是读锁是不能插入到写锁的前面的。
加解锁命令
-- 对表加读锁 lock tables ...... read; -- 对表加写锁 lock tables ...... write; -- 释放锁 unlock tables;
测试
表锁读锁测试
窗口1:对user表加读锁。窗口2:对user表全表读取,正常返回全表数据。窗口2:修改user表中id=6的数据,阻塞。读写冲突。窗口1:修改user表中id=6的数据,报错。窗口1:释放读锁,窗口2的更新数据执行成功。
表锁写锁测试
窗口1:对user表添加写锁。窗口2:全表查询user表,阻塞。窗口1:更新user表中的id=6的数据,更新成功。窗口1:释放锁,窗口2的全表查询返回最新数据。
元空间锁
MySQL5.5版本中引入了元空间锁(matadata lock),当对一个表做增删改查操作的时候,会添加MDL读锁。当对表结构变更操作的时候,会添加MDL写锁。MDL的作用是防止DDL和DML并发的冲突。
MDL锁是系统默认添加的,不需要显式的添加。
测试
窗口1:查询表中的一条数据,这个时候在执行查询语句,会添加MDL读锁。窗口2:添加字段,此时执行的是alter语句,会添加MDL写锁。这个时候窗口1的读锁没有释放,所以alter语句会阻塞。窗口3:查询表中的一条数据,由于窗口2导致的阻塞,在窗口3申请MDL读锁的时候也会造成阻塞。窗口1:提交事务,窗口3获取了MDL读锁,返回查询结果。窗口3:提交事务释放了读锁,窗口2获取写锁,添加字段成功。
行级锁
MySQL的行锁是在引擎层由各个存储引擎实现的。并不是所有的存储引擎都支持行锁,比如MyISAM引擎是不支持行锁的。不支持行锁意味着并发控制的时候只能使用表锁,这也意味着同一个时刻同一个表只有一个更新执行,严重影响了并发。InnoDB是支持行锁的,这也是InnoDB能替代MyISM的重要原因之一。
两阶段锁协议
在InnoDB事务,行锁是需要的时候加上的,但并不是不需要了就立刻释放的,而是需要等到事务结束后才会释放锁。这个就是两阶段锁协议。
事务A执行了两条update语句之后,事务B也执行update语句,但是事务B阻塞直到事务A提交事务。
行锁
我们创建一张简单表t,其中id为主键,a为索引,插入6条数据。
CREATE TABLE `t1` ( `id` int(11) NOT NULL, `a` int(11) DEFAULT NULL, `b` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx` (`a`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; insert into t1 values(0,0,0),(5,5,5),(10,10,10),(15,15,15),(20,20,20),(25,25,25);
间隙锁(Gap Lock)
间隙锁,锁的是两个值的间隙。
对于表t1,6条数据就产生了7个间隙,如下图所示:
我们看前面学习的写锁的例子:
加了写锁的select查询是当前读,读取的是最新的数据值。b字段不是表的索引字段,它会扫描全表将满足条件的行都加上写锁,也会给满足条件的行两边的间隙加上了锁。
间隙锁之间并不会冲突,与间隙锁存在冲突关系的是往这个间隙中插入数据的操作。
next-key lock
行锁和间隙锁的合称为next-key lock每个next-key lock都是一个前开后闭的区间。这里不要混淆了,间隙锁是一个开区间,间隙锁加上行锁生成的next-key lock是一个前开后闭的区间。
间隙锁和next-key lock的引入帮助我们解决了幻读的问题。
间隙锁是可重复隔离级别下才生效的,如果我们把隔离级别设置为读提交,那就没有间隙锁了。
测试
窗口1:使用显式事务,通过for update加写锁,对满足条件的行和间隙加锁。窗口2:更新id为0的行,此行没有加锁更新成功。窗口3:插入数据,满足了(0,5]的next-key lock,阻塞等待。
总结
锁按照锁粒度分为:全局锁、表锁和行锁。
行锁是引擎层的实现,我们文中描述的行锁都是基于InnoDB存储引擎的实现。
可重复度隔离级别下存在间隙锁,如果设置为其他的隔离级别下就没有间隙锁了。间隙锁即是对行数据的两边间隙进行加锁,间隙锁加上行锁合称为next-key lock,它是一个前开后闭的区间。间隙锁解决了幻读的问题。
大家在学习锁的时候还需多动手实践。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。