数据库锁概述

确保事务隔离性的方法之一是要求对数据项以互斥的方式进行访问。也就是说，当一个事务访问某个数据项时，其他任何事务都不能修改该数据项。实现该需求最常用的方法是只允许事务访问当前该事务持有锁(lock)的数据项。

锁的分类

根据不同的分类标准，可以实现不同的锁划分。如根据使用的加锁策略是悲观策略还是乐观策略，可划分为悲观锁和乐观锁；根据加锁的对象是否可以共享，可划分为共享锁和独占锁。等等。

悲观锁和乐观锁

数据库锁一般可以分为两类，一个是悲观锁，一个是乐观锁。
(1) 悲观锁
当我们要对一个数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。这种借助数据库锁机制在修改数据之前先锁定，再修改的方式被称之为悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）。
悲观锁对数据的修改抱有悲观态度的并发控制方式。悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。
但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；另外，还会降低并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据。
(2) 乐观锁
乐观锁（Optimistic Locking)是相对悲观锁而言的，乐观锁假设数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。对事务而言，检测到冲突后，要么执行回滚，要么重试。
乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。

共享锁和排他锁

(1) 共享锁(shared lock，记为S)：如果事务$T_i$获得了数据项Q上的共享型锁，则$T_i$可读但不可写。
(2) 排他锁(exclusive lock，记为X)：如果事务$T_i$获得了数据项Q上的排他型锁，则$T_i$即可写又可读。

表锁和行锁

表锁，按照字面意思理解，就是给表加锁。行锁，按照字面意思理解，就是给某一行加上锁，也就是一条记录加上锁。在MySQL中，行锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁。
表锁并发能力很差。行锁粒度变小，并发能力变强，但是相应的锁的开销变大。
表锁和行锁都分为共享锁和排他锁（独占锁），而更新锁是为了解决行锁升级（共享锁升级为独占锁）的死锁问题。
表锁和行锁一起用，所以为了提高效率才会有意向锁（意向共享锁和意向排他锁）。

更新锁(避免更新产生死锁)

更新锁在的初始化阶段用来锁定可能要被修改的资源，这可以避免使用共享锁造成的死锁现象。
在MySQL的InnoDB 存储引擎中，更新锁不是一种直接可以请求或设置的锁类型。实际上，InnoDB 使用的是一种内部机制来管理锁，包括行级锁和间隙锁，以确保数据的一致性和并发访问的安全。执行一个UPDATE语句时，InnoDB 会自动为涉及的行加上锁，以防止其他事务修改或删除这些行，直到当前事务完成。这个过程中，开发者不需要显式地请求或设置更新锁。
例如，对于以下的update语句：

UPDATE accounts SET balance=900 WHERE id=1

更新操作需要分两步：读取accounts表中id为1的记录 –> 执行更新操作。
如果在第一步使用共享锁，再第二步把锁升级为独占锁，就可能出现死锁现象。例如：两个事务都获取了同一数据资源的共享锁，然后都要把锁升级为独占锁，但需要等待另一个事务解除共享锁才能升级为独占锁，这就很造成了死锁（假设还有一份资源，且构成了循环引用）。
更新锁有如下特征：
加锁与解锁：当一个事务执行update语句时，数据库系统会先为事务分配一把更新锁。当执行更新操作时，会把该更新锁升级为独占锁。完成操作后，释放锁。
注意，更新锁与共享锁是兼容的，也就是说，一个资源可以同时放置更新锁和共享锁，但是最多放置一把更新锁。这样，当多个事务更新相同的数据时，只有一个事务能获得更新锁，然后再把更新锁升级为独占锁，其他事务必须等到前一个事务结束后，才能获取得更新锁，这就避免了死锁。同时，更新锁允许多个事务同时读锁定的资源，但不允许其他事务修改它。

意向锁

对于意向锁，官方文档描述如下：

Intention locks are table-level locks that indicate which type of lock (shared or exclusive) a transaction requires later for a row in a table

简单来说，意向锁是表示意图对表中的行添加共享锁或排他锁的表锁。
当表锁和行锁共存时，必须考虑如下情况：事务A锁住了表中的一行，让这一行只能读，不能写。之后，事务B申请整个表的写锁。如果事务B申请成功，那么理论上它就能修改表中的任意一行，这与A持有的行锁是冲突的。数据库需要避免这种冲突，就是说要让B的申请被阻塞，直到A释放了行锁。
数据库要怎么判断这个冲突呢？
step1：判断表是否已被其他事务用表锁锁表
step2：判断表中的每一行是否已被行锁锁住。
注意step2，这样的判断方法效率实在不高，因为需要遍历整个表。于是就有了意向锁。在意向锁存在的情况下，事务A必须先申请表的意向共享锁，成功后再申请一行的行锁。
在意向锁存在的情况下，上面的判断可以改成：
step1：不变
step2：发现表上有意向共享锁，说明表中有些行被共享行锁锁住了，因此，事务B申请表的写锁会被阻塞。
注意：申请意向锁的动作是数据库完成的，就是说，事务A申请一行的行锁的时候，数据库会自动先开始申请表的意向锁，不需要我们程序员使用代码来申请。

锁与数据库隔离级别

了解了数据的锁机制，数据库的隔离级别也就好理解多了。每一种隔离级别满足不同的数据要求，使用不同程度的锁。
Read Uncommitted，读写均不使用锁，数据的一致性最差，也会出现许多逻辑错误。
Read Committed，使用写锁，但是读会出现不一致，不可重复读。
Repeatable Read, 使用读锁和写锁，解决不可重复读的问题，但会有幻读。
Serializable, 使用事务串形化调度，避免出现因为插入数据没法加锁导致的不一致的情况。
(1)读未提交(Read Uncommitted)
一个事务中的读操作可能读到另一个事务中未提交修改的数据，如果事务发生回滚就可能造成错误。
例子：A打100块给B，B看账户，这是两个操作，针对同一个数据库，两个事物，如果B读到了A事务中的100块，认为钱打过来了，但是A的事务最后回滚了，造成损失。
避免这些事情的发生就需要我们在写操作的时候加锁，使读写分离，保证读数据的时候，数据不被修改，写数据的时候，数据不被读取。从而保证写的同时不能被另个事务写和读。
(2)读已提交(Read Committed)
我们加了写锁，就可以保证不出现脏读，也就是保证读的都是提交之后的数据，但是会造成不可重读，即读的时候不加锁，一个读的事务过程中，如果读取数据两次，在两次之间有写事务修改了数据，将会导致两次读取的结果不一致，从而导致逻辑错误。
(3) 可重复读(Repeatable Read）
解决不可重复读问题，一个事务中如果有多次读取操作，读取结果需要一致（指的是固定一条数据的一致，幻读指的是查询出的数量不一致）。 这就牵涉到事务中是否加读锁，并且读操作加锁后是否在事务commit之前持有锁的问题，如果不加读锁，必然出现不可重复读，如果加锁读完立即释放，不持有，那么就可能在其他事务中被修改，若其他事务已经执行完成，此时该事务中再次读取就会出现不可重复读，所以读锁在事务中持有可以保证不出现不可重复读，写的时候必须加锁且持有，这是必须的了，不然就会出现脏读。Repeatable Read（可重读）也是MySql的默认事务隔离级别，上面的意思是读的时候需要加锁并且保持
(4) 可串行化（Serializable）
解决幻读问题，在同一个事务中，同一个查询多次返回的结果不一致。事务A新增了一条记录，事务B在事务A提交前后各执行了一次查询操作，发现后一次比前一次多了一条记录。幻读是由于并发事务增加记录导致的，这个不能像不可重复读通过记录加锁解决，因为对于新增的记录根本无法加锁。需要将事务串行化，才能避免幻读。
这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

死锁（Deadlock）

所谓死锁：是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。由于资源占用是互斥的，当某个进程提出申请资源后，使得有关进程在无外力协助下，永远分配不到必需的资源而无法继续运行，这就产生了一种特殊现象死锁。在数据库里则指事务。

产生死锁的四个必要条件

(1) 互斥条件：一个资源每次只能被一个进程使用。
(2) 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
(3) 不剥夺条件：进程已获得的资源，在末使用完之前，不能强行剥夺。
(4) 循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系。

死锁预防

死锁检测是事务在死锁发生时进行的，除了预防之外，我们还能够进行死锁预防。这里主要介绍 将数据元素有序锁的管理，和基于时间戳检测的死锁预防。
(1) 元素有序锁管理
将数据元素按照某种固定顺序进行排列，然后申请数据元素的锁都必须按照顺序进行，那么就不会产生由于事务等待图而导致的死锁。
(2) 时间戳检测死锁
基于时间戳进行死锁检测是将每一个事务与一个时间戳关联起来，该时间戳与基于时间戳并发控制不同，该时间戳仅用于死锁检测，且该时间戳在事务进行重置后仍不变。时间戳在事务T等待另一事务U持有的锁时，根据时间戳的大小可以有两种不同的方案。

死锁检测与恢复

死锁检测的方法，包括超时死锁检测和等待图死锁判断。
(1) 超时死锁检测
超时死锁检测是最简单的检测方法，如果事务执行超过一定时间，那么就将该事务进行回滚。该方法主要存在的问题是不能便于定义超时时间，也可能造成非死锁的事务回滚。
(2) 等待图死锁检测
有向图
在锁表中，为每一个元素维护了等待X上的锁和X的封锁事务。在等待图中，所有事务是一个结点，对于满足以下要求的事务U和事务T：U持有X上的锁；T等待X上的一个锁；除非U先释放持有X上的锁，否则T不能获得X上的封锁，那么存在 从T到U的弧。
如果等待图中不存在环，那么所有事务最终是能够完成的；但是如果图中有环，那么环中的事务将不能够继续向前，存在死锁。
当一个检测算法判定存在死锁时，系统必须从死锁中恢复。解除死锁最通常的做法是回滚一个或多个事务。需采取的动作有三个：
(1) 选择牺牲者
(2) 回滚
(3) 饿死

参考

编写文档时，未统计引用。如果已明确参考了您的文档，请联系我补充。

原创不易，如果本文对您有帮助，欢迎关注我，谢谢 ~_~