目录
一、简述数据库的锁
锁是数据库系统区别于文件系统的一个关键特性,锁机制用于管理对共享资源的并发访问。下面我们以MySQL数据库的InnoDB引擎为例,简单介绍一下锁的特点。
如果一个事务T1已经获得了行r的共享锁,那么另外的事务T2可以立即获得行r的共享锁,因为读取并没有改变行r的数据,称这种情况为锁兼容。但若有其它的事务T3想获得行r的排它锁,则其必须等待事务T1、T2释放行r上的共享锁,这种情况称为锁不兼容。下图显示了共享锁和排它锁的兼容性,可以发现X锁与任何的锁都不兼容,而S锁仅和S锁兼容。需要特别注意的是,S锁和X锁都是行锁,兼容是指对同一记录(row)锁的兼容性情况。
X | S | |
X | 不兼容 | 不兼容 |
S | 不兼容 | 兼容 |
锁的粒度:InnoDB存储引擎支持多粒度锁定,这种锁定允许事务在行级上的锁和表级上的锁同时存在。为了支持在不同粒度上进行加锁操作,InnoDB存储引擎支持一种额外的锁方式,称之为意向锁。意向锁是将锁定的对象分为多个层次,意向锁意味着事务希望在更细粒度上进行加锁。
InnoDB存储引擎支持意向锁设计比较简练,其意向锁即为表级别的锁。设计目的主要是为了在一个事务中揭示下一行被请求的锁类型。其支持两种意向锁:
1、意向共享锁(IS Lock),事务想要获得一张表中某几行的共享锁。
2、意向排它锁(IX Lock),事务想要获得一张表中某几行的排它锁。
由于InnoDB存储引擎支持的是行级别的锁,因此意向锁其实不会阻塞除全表扫以外的任何请求。所以表级意向锁与行级锁的兼容性如下所示:
IS | IX | S | X | |
IS | 兼容 | 兼容 | 兼容 | 不兼容 |
IX | 兼容 | 兼容 | 不兼容 | 不兼容 |
S | 兼容 | 不兼容 | 兼容 | 不兼容 |
X | 不兼容 | 不兼容 | 不兼容 | 不兼容 |
锁的算法:InnoDB存储引擎有3种行锁的算法,其分别是:
1、Record Lock:单个行记录上的锁。
2、Gap Lock:间隙锁,锁定
3、Next-Key Lock:Gap Lock+Record Lock,锁定一个范围,并且锁定记录本身。
Record Lock 总是会去锁住索引记录,如果InnoDB存储引擎表在建立的时候没有设置任何一个索引,那么这时InnoDB存储引擎会使用隐式的主键来进行锁定。Next-Key Lock是结合了Gap Lock和Record Lock的一种锁定算法,在Next-Key Lock算法下,InnoDB对于行的查询都是采用这种锁定算法。采用Next-Key Lock的锁定技术称为Next-Key Locking,其设计没目的是为了解决Phantom Problem(幻读)。利用这种锁定技术,锁定的不是单个值,而是一个范围,是谓词锁(Predict Lock)的一种改进。
关于死锁:死锁是指两个或两个以上的事务在执行过程中,因争夺资源而造成的一种互相等待的现象。若无外力作用,事务将无法推进下去。
锁升级:锁升级(Lock Escalation)是指将当前锁的粒度降低。举例来说,数据库可以把一个表的1000个行锁升级为一个页锁,或者将页锁升级为表锁。
InnoDB存储引擎不存在锁升级的问题。因为其不是根据每个记录来产生行锁的,相反,其根据每个事务访问的每个页对锁进行管理的,采用的是位图的方式。因此不管一个事务锁住页中一个记录还是多个记录,其开销通常都是一致的。
二、简述间隙锁
InnoDB存储引擎有3种行锁的算法,间隙锁(Gap Lock)是其中之一。间隙锁用于锁定一个范围,但不包含记录本身。它的作用是为了阻止多个事务将记录插入到同一范围内,而这会导致幻读问题的产生。
三、InnoDB中的行级锁是如何实现的
InnoDB行级锁是通过给索引上的索引项加锁来实现的。只有通过索引条件检索数据,InnoDB才使用行级锁,否则,InnoDB将使用表锁。
当表中锁定其中的某几行时,不同的事务可以使用不同的索引锁定不同的行。另外,不论使用主键索引、唯一索引还是普通索引,InnoDB都会使用行锁来对数据加锁。
四、数据库在什么情况下会发生死锁
死锁是指两个或两个以上的事务在执行过程中,因争夺资源而造成的一种互相等待的现象。若无外力作用,事务将无法推进下去。下表演示了死锁的一种经典情况,即A等待B、B等待A,这种死锁问题被称为AB-BA死锁。
时间 | 会话A | 会话B |
1 | BEGIN: | |
2 | mysql>SELECT * FROM t WHERE a = 1 FOR UPDATE; ************1.row************ a:1 1 row in set(0.00sec) | BEGIN: |
3 | mysql>SELECT * FROM t WHERE a = 2 FOR UPDATE; ************1.row************ a:2 1 row in set(0.00sec) | |
4 | mysql>SELECT * FROM t WHERE a = 2 FOR UPDATE; #等待 | |
5 | mysql>SELECT * FROM t WHERE a = 1 FOR UPDATE; ERROR 1213(40001): Deadlock found when trying to get lock;try restarting transaction |
五、简述数据库死锁的解决办法
解决死锁问题最简单一种方法是超时,即当两个事务互相等待时,当一个等待时间超过设置的某一阈值时,其中一个事务进行回滚,另一个等待的事务就能继续进行。
除了超时机制,当前数据库还都普遍采用wait-for graph(等待图)的方式进行死锁检测。较之超时的解决方案,这是一种更为主动的死锁检测方式。InnoDB存储引擎也采用的这种方式。wait-for graph 要求数据库保存以下两种信息:
1、锁的信息链表;
2、事务等待链表;
通过以上链表可以构造出一张图,而在这个图中若存在回路,就代表存在死锁,因此资源间相互发生等待。这是一种较为主动的死锁检测机制,在每个事务请求锁并发生等待时都会判断是否存在回路,若存在则有死锁,通常来说InnoDB存储引擎选择回滚undo量最小的事务。
标签:之锁,Lock,数据库,事务,兼容,死锁,InnoDB,锁定 From: https://blog.csdn.net/L_peanut/article/details/140341458