MySQL从入门到精通(九) MySQL锁,各种锁

MySQL从入门到精通(九) MySQL锁,各种锁,第1张

锁是计算机协调多个进程或线程并发访问某一资源的机制,在数据库中,除传统的计算资源(CPU、RAM、I/O)争用外,数据也是一种供许多用户共享的资源,如何保证数据并发访问的一致性,有效性是所有数据库必须解决的一个问题,锁冲突也是影响数据库并发访问性能的一个重要因素,从这个角度来说,锁对数据库而言是尤其重要,也更加复杂。MySQL中的锁,按照锁的粒度分为:1、全局锁,就锁定数据库中的所有表。2、表级锁,每次 *** 作锁住整张表。3、行级锁,每次 *** 作锁住对应的行数据。

全局锁就是对整个数据库实例加锁,加锁后整个实例就处于只读状态,后续的DML的写语句,DDL语句,已经更新 *** 作的事务提交语句都将阻塞。其典型的使用场景就是做全库的逻辑备份,对所有的表进行锁定,从而获取一致性视图,保证数据的完整性。但是对数据库加全局锁是有弊端的,如在主库上备份,那么在备份期间都不能执行更新,业务会受影响,第二如果是在从库上备份,那么在备份期间从库不能执行主库同步过来的二进制日志,会导致主从延迟。

解决办法是在innodb引擎中,备份时加上--single-transaction参数来完成不加锁的一致性数据备份。

添加全局锁: flush tables with read lock解锁 unlock tables。

表级锁,每次 *** 作会锁住整张表.锁定粒度大,发送锁冲突的概率最高,并发读最低,应用在myisam、innodb、BOB等存储引擎中。表级锁分为: 表锁、元数据锁(meta data lock, MDL)和意向锁。

表锁又分为: 表共享读锁 read lock、表独占写锁write lock

语法: 1、加锁 lock tables 表名 ... read/write

2、释放锁 unlock tables 或者关闭客户端连接

注意: 读锁不会阻塞其它客户端的读,但是会阻塞其它客户端的写,写锁既会阻塞其它客户端的读,又会阻塞其它客户端的写。大家可以拿一张表来测试看看。

元数据锁,在加锁过程中是系统自动控制的,无需显示使用,在访问一张表的时候会自动加上,MDL锁主要作用是维护表元数据的数据一致性,在表上有活动事务的时候,不可以对元数据进行写入 *** 作。为了避免DML和DDL冲突,保证读写的正确性。

在MySQL5.5中引入了MDL,当对一张表进行增删改查的时候,加MDL读锁(共享);当对表结构进行变更 *** 作时,加MDL写锁(排他).

查看元数据锁:

select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema_metadata_locks

意向锁,为了避免DML在执行时,加的行锁与表锁的冲突,在innodb中引入了意向锁,使得表锁不用检查每行数据是否加锁,使用意向锁来减少表锁的检查。意向锁分为,意向共享锁is由语句select ... lock in share mode添加。意向排他锁ix,由insert,update,delete,select。。。for update 添加。

select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from performance_schema.data_lock

行级锁,每次 *** 作锁住对应的行数据,锁定粒度最小,发生锁冲突的概率最高,并发读最高,应用在innodb存储引擎中。

innodb的数据是基于索引组织的,行锁是通过对索引上的索引项加锁来实现的,而不是对记录加的锁,对于行级锁,主要分为以下三类:

1、行锁或者叫record lock记录锁,锁定单个行记录的锁,防止其他事物对次行进行update和delete *** 作,在RC,RR隔离级别下都支持。

2、间隙锁Gap lock,锁定索引记录间隙(不含该记录),确保索引记录间隙不变,防止其他事物在这个间隙进行insert *** 作,产生幻读,在RR隔离级别下都支持。

3、临键锁Next-key-lock,行锁和间隙锁组合,同时锁住数据,并锁住数据前面的间隙Gap,在RR隔离级别下支持。

innodb实现了以下两种类型的行锁

1、共享锁 S: 允许一个事务去读一行,阻止其他事务获得相同数据集的排他锁。

2、排他锁 X: 允许获取排他锁的事务更新数据,阻止其他事务获得相同数据集的共享锁和排他锁。

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锁进行搜索和索引扫描,以防止幻读。

间隙锁唯一目的是防止其它事务插入间隙,间隙锁可以共存,一个事务采用的间隙锁不会阻止另一个事务在同一间隙上采用的间隙锁。

MySQL 中原数据锁是系统自动控制添加的,对于用户来说无需显示调用,当我们使用一张表的时候就会加上原数据锁。

原数据锁的作用是为了保护表原数据的一致性,如果在表上有活动事务的时候,不可以对元数据进行写入 *** 作。也就是为了避免DML 和DDL 之间的冲突,保证读写的正确性。

说白了就是, 在对数据表进行读写 *** 作的时候,不能进行修改表结构的 *** 作

如上图所示,在执行select *** 作的时候,MySQL 会自动加上shared_read 锁,在insert,update, delete 以及 select for update *** 作的时候会加上shared_write 锁,这两类锁是兼容的。

在执行alter table *** 作的时候,会加上 exclusive 锁,这个锁与shared_read 和 shared_write 锁 是互斥的,换句话说在 做查询和更新表数据的时候,是不能够修改表结构 的。

来看个例子

首先开启事务,使用select 语句会针对表加上shared_read的共享锁

begin

select * from course

此时查看原数据锁的信息

select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema.metadata_locks

通过上图我们可以发现,course 表加上了shared_read锁。

接着,开启另外一个事务,记住刚才的事务不要commit

begin

update course set name = 'Jason' where id =2

如上图所示,此时的update 语句可以执行成功,并没有被阻塞。说明select 和update 是不冲突的,他们的锁是兼容的。

再次查看原数据锁

select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema.metadata_locks

从上面的截图可以看出,此时原数据锁的表中记录了两条记录分别是针对course 表的shared_read 和 shared_write 锁,也刚好对应我们执行的select 和update *** 作。

最后,我们再启动第三个客户端,并且启动 第三个事务,执行alter语句,在course 表中加入一个字段hello 如下 。

begin

alter table course add column hello int

由于之前的事务没有提交所以修改表的 *** 作会被阻塞, 因为shared_read 以及 shared_write 这两个锁 与 exclusive之间是互斥的,所以会阻塞

此时,回到最开始的两个客户端,对两个事务进行commit *** 作,再返回到第三个事务执行的alter 语句出,发现语句顺利执行。

mysql 为并发事务同时对一条记录进行读写时,提出了两种解决方案:

1)使用 mvcc 的方法,实现多事务的并发读写,但是这种读只是“快照读”,一般读的是历史版本数据,还有一种是“当前读”,一般加锁实现“当前读”,或者 insert、update、delete 也是当前读。

2)使用加锁的方法,锁分为共享锁(读锁),排他锁(写锁)

快照读:就是select

当前读:特殊的读 *** 作,插入/更新/删除 *** 作,属于当前读,处理的都是当前的数据,需要加锁。

mysql 在 RR 级别怎么处理幻读的呢?一般来说,RR 级别通过 mvcc 机制,保证读到低于后面事务的数据。但是 select for update 不会触发 mvcc,它是当前读。如果后面事务插入数据并提交,那么在 RR 级别就会读到插入的数据。所以,mysql 使用 行锁 + gap 锁(简称 next-key 锁)来防止当前读的时候插入。

Gap Lock在InnoDB的唯一作用就是防止其他事务的插入 *** 作,以此防止幻读的发生。

Innodb自动使用间隙锁的条件:


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/7314935.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-04
下一篇 2023-04-04

发表评论

登录后才能评论

评论列表(0条)

保存