目录
MySQL中的锁,按照锁的粒度分,分为以下三类:
(1)全局锁:锁定数据库中的所有表。
(2)表级锁:每次操作锁住整张表。
(3)行级锁:每次操作锁住对应的行数据。
1全局锁—一致性数据备份
1.1全局锁介绍
全局锁就是对整个数据库实例加锁,加锁后整个实例就处于只读状态,后续的DML的写语句,DDL语句,已经更新操作的事务提交语句都将被阻塞。
其典型的使用场景是做全库的逻辑备份,对所有的表进行锁定,从而获取一致性视图,保证数据的完整性。
对数据库进行进行逻辑备份之前,先对整个数据库加上全局锁,一旦加了全局锁之后,其他的DDL、 DML全部都处于阻塞状态,但是可以执行DQL语句,也就是处于只读状态,而数据备份就是查询操作。 那么数据在进行逻辑备份的过程中,数据库中的数据就是不会发生变化的,这样就保证了数据的一致性和完整性。
1.2语法
1.3 一致性备份案例
(这里试试在window上远程访问Linux系统中的数据库)
(1)先查到Linux系统中的IP地址
学习:
ip addr命令一共输出了4项:
1)ens33是物理网卡驱动程序创建的,
2)lo是内核启动时自己创建的环回网络接口
3)virbr0和virbr0-nic则是我们自己创建的veth peer虚拟网络接口。
我们可以将每个网络接口都视作一条管道,管道的一端连接到本机内核路由子系统,而另一端根据类型各有不同。物理网卡对应的网络接口另一端通向设备驱动程序; veth peer类型的接口另一端通向对方;tun类型设备的另一端通向用户应用程序。
另外,从上面的输出内容中还可以注意到的是:网络接口上并不是一定都有IP地址(本文提到的IP地址专指IPv4地址),比如virbr0和virbr0-nic后面都没有IP地址。IP地址还是属于主机的,而不是某个网络接口。
(2)Windows本地远程连接代码:mysql -h192.168.145.128 -uroot -p
开3个,模拟三个客户端:
(3)给一个客户端加上全局锁,相当于数据库实例192.168.145.128已经被锁住了,
加上全局锁:flush tables with read lock;
加上之后,所有客户端都只能读了,不能进行修改了。堵塞状态可以输入Ctrl+C退出当前。
(4)备份数据
mysqldump -h192.168.145.128 -uroot -p1234 itheima > D:/itheima.sql
注意是在Windows下的命令(exit退出到Windows命令行执行),而不是在mysql中;
要加入远程连接参数-h192.168.145.128,要访问的是远程的,而不是Windows上的;
最后没有;分号!!!
D盘中成功有备份文件,里面创建表插入数据的SQL语句都有。
(5)释放锁并进行修改操作。
1.4 全局锁特点
数据库中加全局锁,是一个比较重的操作,存在以下问题:
(1)如果在主库上备份,那么在备份期间都不能执行更新,业务基本上就得停摆。
(2)如果在从库上备份,那么在备份期间从库不能执行主库同步过来的二进制日志(binlog),会导致主从延迟。
此外:在InnoDB引擎中,我们可以在备份时加上参数 --single-transaction 参数来完成不加锁的一致 性数据备份。
2表级锁
2.1表锁
对于表锁,分为两类:
表共享读锁(read lock)
表独占写锁(write lock)
语法:
加锁:lock tables 表名... read/write。
释放锁:unlock tables / 客户端断开连接 。
2.1.1共享读锁
测试:
2.1.2独占写锁
测试:
结论:
读锁不会阻塞其他客户端的读,但是会阻塞写。
写锁既会阻塞其他客户端的读,又会阻塞 其他客户端的写。
2.2元数据锁
meta data lock , 元数据锁,简写MDL。MDL加锁过程是系统自动控制,无需显式使用,在访问一张表的时候会自动加上。MDL锁主要作用是维护表元数据的数据一致性,在表上有活动事务的时候,不可以对元数据进行写入操作。为了避免DML与DDL冲突,保证读写的正确性。
这里的元数据,大家可以简单理解为就是一张表的表结构。 也就是说,某一张表涉及到未提交的事务时,是不能修改这张表的表结构的。在MySQL5.5中引入了MDL,当对一张表进行增删改查的时候,加MDL读锁(共享);当对表结构进行变更操作的时候,加MDL写锁(排他)。
常见的SQL操作时,所添加的元数据锁
演示:新建两个shell远程连接窗口,Ctrl+L清除命令。
(1)当执行SELECT、INSERT、UPDATE、DELETE等语句时,添加的是元数据共享锁(SHARED_READ / SHARED_WRITE),之间是兼容的。
(2)当执行alter语句时,添加的是元数据共享锁(EXCLUSIVE),会阻塞元数据排他锁,之间是互斥的。
只有当一个事务提交完之后,alter语句才能继续。
查看元数据锁的加锁情况:
select object_type, object_schema, object_name, lock_type, lock_duration from performance_schema.metadata_locks ;
2.3意向锁
2.3.1介绍
为了避免DML在执行时,加的行锁与表锁的冲突,在InnoDB中引入了意向锁,使得表锁不用检查每行数据是否加锁,使用意向锁来减少表锁的检查。
以通过以下SQL,查看意向锁及行锁的加锁情况:
select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from performance_schema.data_locks;
分类:
(1)意向共享锁(IS): 由语句select ... lock in share mode添加。与表锁共享锁 (read)兼容,与表锁排他锁(write)互斥。
(2)意向排他锁(IX): 由insert、update、delete、select...for update添加 。与表锁共享锁(read)及排他锁(write)都互斥,意向锁之间不会互斥。
2.3.2演示
为id=1这行加上行锁的共享锁,同时给stu表加上意向共享锁:
select * from stu where id =1 lock in share mode;
给表加读锁可以执行,加写锁就不行。意向共享锁与表读锁是兼容的,与表写锁是互斥的。
加锁:lock tables stu read/write;
解锁:unlock tables;
(2)意向排他锁与表读锁、写锁都是互斥的
执行:update stu set age=66 where id = 8;
这时候加表读锁会被堵塞,直到事务1被提交之后。
3 行级锁
行级锁,每次操作锁住对应的行数据。锁定粒度最小,发生锁冲突的概率最低,并发度最高。应用在 InnoDB存储引擎中。
InnoDB的数据是基于索引组织的,行锁是通过对索引上的索引项加锁来实现的,而不是对记录加的锁。对于行级锁,主要分为以下三类:
3.1行锁
InnoDB实现了以下两种类型的行锁:
共享锁(S):允许一个事务去读一行,阻止其他事务获得相同数据集的排它锁。
排他锁(X):允许获取排他锁的事务更新数据,阻止其他事务获得相同数据集的共享锁和排他锁。
两种行锁的兼容情况如下:
常见的SQL语句,在执行时,所加的行锁如下:
默认情况下,InnoDB在 REPEATABLE READ事务隔离级别运行,InnoDB使用 next-key 锁进行搜 索和索引扫描,以防止幻读。、
(1)针对唯一索引进行检索时,对已存在的记录进行等值匹配时,将会自动优化为行锁。
(2)InnoDB的行锁是针对于索引加的锁,不通过索引条件检索数据(就是检索的这个条件没有索引),那么InnoDB将对表中的所有记录加锁,此时就会升级为表锁。
3.2间隙锁&临键锁
认情况下,InnoDB在 REPEATABLE READ事务隔离级别运行,InnoDB使用 next-key 锁进行搜 索和索引扫描,以防止幻读。
(1)索引上的等值查询(唯一索引),给不存在的记录加锁时, 优化为间隙锁 。
示例:id=5这个记录是不存在的,这时候会优化为间隙锁。
(2)索引上的等值查询(非唯一普通索引),向右遍历时最后一个值不满足查询需求时,next-key lock 退化为间隙锁。
(3)索引上的范围查询(唯一索引)--会访问到不满足条件的第一个值为止
注意:间隙锁唯一目的是防止其他事务插入间隙。间隙锁可以共存,一个事务采用的间隙锁不会 阻止另一个事务在同一间隙上采用间隙锁。