目录
一、简述数据库的锁
二、简述间隙锁
三、InnoDB中的行级锁是如何实现的
四、数据库在什么情况下会发生死锁
五、简述数据库死锁的解决办法
一、简述数据库的锁
锁是数据库系统区别于文件系统的一个关键特性，锁机制用于管理对共享资源的并发访问。下面我们以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量最小的事务。