MySQL ---锁

 

 

 

 

 

 

 

 

 

 

 

 不加锁，数据备份

 

 

 出现数据不一致问题

 

 

 先锁住DB，利用系统提供的备份工具mysqldump 备份，期间只能操作DQL, DML 与DDL不能操作，备份结束产生xxx.sql文件，备份结束，解锁DB

 

 

相关命令

#加全局锁
flush tables with read lock;

#开始备份，在windows命令行中执行，不要在mysql环境里执行
mysqldump -h192.168.200.202 -uroot -p1234 itcast >D:/itcast.sql;

#解锁
unlock tables ;

　

 

 

 

备份成功之后，解锁

 

 

 

 

 

 上面的操作不用加全局锁

 

 

 

 

 

 读锁演示：

 

 

 客户端A给表加了读锁，不会阻碍其他客户端B的DQL操作，同时客户端A自己的DDL与DML也是无法操作的

 

 

 

 

 

 

 

 

 

 

 

 

在事务中查询与更新操作的时候，系统都会自动加入元数据对应的锁SHARED_READ与SHARED_WRITE，这两类锁都是兼容的，所以两个事务中DQL与DML都成功了

 

 

左边事务开启之后执行了DQL语句，系统自动加上了MDL的SHARED_READ， 右边执行DDL操作被阻塞，因为左边事务没有提交，右边的EXCLUSIVE与左边的SHARED_READ互斥，被阻塞。

左边提交事务之后，右边的阻塞解除，语句执行成功

 

 

 

 

 

 

 

 

 事务开启并不会出现新的锁，执行了相应的SQL语句之后才会出现对应锁

如DQL之后，出现SHARE_READ

 

 

 右边也开启事务，执行DML语句之后，出现 SHARED_WRITE

 

 

 如果没有意向锁，线程B需要在给表加锁前要检测表里数据的每一行是否加锁了（行锁）

 

 

 有了意向锁的情况，当线程A开启事务，对id=3这行数据做更新操作，会给这行加锁，同时给该表加意向锁，线程B想对表加锁的时候，会先去检测表的意向锁是否与自己要加的表锁兼容，兼容就直接加锁，不兼容则处于阻塞状态

当线程A提交事务之后，解锁，线程B拿到表锁

 

 

 

 

 

 

 

 

 

左边查询语句加表锁，右边有查询到该表锁IS（意向共享锁）

 右边client给表也加一个读锁，也成功了,IS与读锁兼容

解锁，再给表加写锁，写锁被阻塞了，因为跟意向锁IS互斥

 左边提交事务，相关的行锁表锁都会释放，右边阻塞的写锁成功了

 

 左边更新语句直接给表加意向排他锁，右边查看锁

 

 右边给表加读锁堵塞，跟左边加的意向排他锁互斥。

当左边事务提交之后，右边加锁阻塞解除

 

 

 

 RR（repeatable read)

间隙锁：如6与12之间，不让插入

临键锁：如12与16之间不让插入

 

 

 

 

 

 

 

 

 

 

 

 

 

 左边开启一个事务，执行一条普通的查询语句，右边查询加锁情况---为空

对应 select （正常）---不加任何锁

 都加共享锁（s行锁），可兼容

如果右边加的是x排他锁,则会被阻塞，如下：

 

排他锁与排他锁之间互斥，如下：

 

 左右都去更新同一行记录，右边的被阻塞了

当左边事务提交之后，右边的阻塞解除，更新执行完毕

 

 

 

 左边事务没有通过索引检索，导致给整个表加锁，右边的更新操作被阻塞

给name字段加上索引后执行更新操作，加的是行锁的排他锁，client 2执行其他行的更新操作不受影响，如下：

 

 

 

 

 

 

 左边给不存在的id 更新，在id 3与8之间加上了间隙锁（x , GAP）,不包含3和8

这时如果其他事务想更新3到8之间数据会被阻塞，如下图：

 

 更新id=7的语句被阻塞了

左边事务一提交，左边加的锁解除，右边语句执行成功

 

 可以看到id=7数据插入到表中了

 

 

 当对二级索引等值查询时，如18，会对18之前和18与29之间这段间隙加锁（红色标识）

 

 左边给age加上索引，开启事务，查询时加上共享锁，右边查询到的是给行加上的s, GAP锁