# 锁
# Innodb存储引擎中的锁
# 锁的类型
Innodb存储引擎实现了如下两种标准的行级锁：
- 共享锁(
S Lock)，允许事务读取一行数据，又称为读锁 - 排它锁(
X Lock)，允许事务删除或者更新一行数据，又称为写锁、独占锁。
共享锁和排他锁的兼容性：
| - | S | X |
|---|---|---|
| S | 兼容 | 不兼容 |
| X | 不兼容 | 不兼容 |
从表中可以发现X锁与任何的锁都不兼容，而S锁仅和S锁兼容。需要特别注意的是，S锁和X锁都是行锁，兼容是指对同一记录（row）锁的兼容性情况。
此外，Innodb存储引擎支持多粒度（granular）锁定，这种锁定允许事务在行级上的锁和表级上的锁同时存在。为了支持在不同粒度上进行加锁操作，Innodb存储引擎支持一种额外的锁方式，称之为意向锁（Intention Lock）。
Innodb存储引擎支持意向锁设计比较简练，其意向锁即为表级别的锁。设计目的主要是为了在一个事务中揭示下一行（数据库->表->页->行记录）将被请求的锁类型。其支持两种意向锁：
- 意向共享锁(IS Lock)，事务想要获得一张表中某几行的共享锁
- 意向排他锁(IX Lock)，事务想要获得一张表中某几行的排他锁
由于Innodb存储引擎支持的是行级别的锁，因此意向锁不会阻塞除全表扫描以后的任何请求。故表级意向锁与行级锁的兼容性如下表：
| - | IS | IX | S | X |
|---|---|---|---|---|
| IS | 兼容 | 兼容 | 兼容 | 不兼容 |
| IX | 兼容 | 兼容 | 不兼容 | 不兼容 |
| S | 兼容 | 不兼容 | 兼容 | 不兼容 |
| X | 不兼容 | 不兼容 | 不兼容 | 不兼容 |
# 一致性非锁定读
一致性非锁定读(consistent nonlocking read)是指Innodb存储引擎通过多版本控制(multi versioning)的方式来读取当前执行时间数据库中行的数据，如果读取的行正在执行DELETE或UPDATE操作，这时读取操作不会因此等待行上锁的释放。相反的，Innodb会去读取行的一个快照数据
上面展示了Innodb存储引擎一致性非锁定读。之所以称为非锁定读，因为不需要等待访问的行上X锁的释放。快照数据是指该行之前版本的数据，该实现是通过undo段来完成。而undo用来事务中的回滚数据，因此快照数据本身没有额外的开销，此外，读取快照数据不需要上锁，因为没有事务需要对历史数据进行修改操作。
可以看到，非锁定读机制极大地提高了数据库的并发性，在Innodb存储引擎的默认设置下，这是默认的读写方式，即读不会占用和等待表上的锁。但是在不同的事务隔离级别下，读取的方式不同，并不是每个事务隔离级别下都是采用非锁定的一致性读，此外，即使使用非锁定的一致性读，但是对于快照数据的定义也各不相同。
快照其实是当前行数据之前的历史版本，每行记录可能有多个版本，如图显示，一个行记录可能有不止一个快照数据，一般称这种技术为多版本技术，由此带来的并发控制，称为多版本并发控制(Multi Version Concurrency Control,MVCC (opens new window))
在事务隔离级别RC和RR下，Innodb存储引擎使用非锁定的一致性读。然而，对于快照数据的定义却不相同。在RC事务隔离级别下，对于快照数据，非一致性读总是读取被锁定行的最新一份快照数据。而在RR事务隔离级别下，对于快照数据，非一致性读总是读取事务开始时的行数据版本。
# 一致性读定锁
某些情况下，用户需要显式地对数据库读取操作进行加锁以保证数据逻辑的一致性。而这就要求数据库支持加锁语句，即使是对于SELECT的只读操作，Innodb存储引擎对于SELECT语句支持两种一致性的锁定读(locking read)操作：
- SELECT...FOR UPDATE (X锁)
- SELECT...LOCK IN SHARE MODE (S锁)
SELECT...FOR UPDATE对读取的行记录加上一个X锁，其他事务不能对已锁定的行加上任务锁。SELECT...LOCK IN SHARE MODE对读取的行记录加上一个S锁，其他事务可以向被锁定的行加S锁，但是如果加X锁，则会被阻塞。
对于一致性非锁定读，即使读取的行已被执行了SELECT...FOR UPDATE，也是可以进行读取的，这是因为MVCC。此外，SELECT...FOR UPDATE，SELECT...LOCK IN SHARE MODE必须在一个事务中，当事务提交了，锁也就释放了。因此在使用上诉两句SELECT锁定语句时，务必加上BEGIN,START TRANSACTION或者SET AUTOCOMMIT=0。
# 锁的算法
Innodb存储引擎行锁有3中算法，其分别是：
- Record Lock: 单个行记录上的锁
- Gap Lock: 间隙锁，锁定一个范围，但不包括记录本身
- Next-Key Lock : Gap Lock+Record Lock ，锁定一个范围，并且锁定记录本身
用户可以通过以下两种方式来显式地关闭间隙锁（Gap Lock）：
- 将事务的隔离级别设置为READ COMMITTED
- 将参数
innodb_locks_unsafe_for_binlog设置为1
在上述的配置下，除了外键约束和唯一性检查依然需要Gap Lock，其余情况仅使用Record Lock进行锁定。但需要注意的是，上述设置破坏了事务的隔离性，并且对于replication可能会导致主从数据的不一致。此外，从性能上来看， READ COMMITTED也不会优于默认的事务隔离级别READ REPEATABLE。
# 解决 Phantom Problem（幻读）
在默认的事务隔离级别下，即READ REPEATABLE下，Innodb存储引擎采用Next-Key Locking机制来避免实时读情况下的Phantom Problem（幻读）。Phantom Problem是指在同一事务下，连续执行两次同样的SQL语句，可能导致不同的结果，第二次的SQL语句可能会返回之前不存在的行。
# 死锁
死锁是指两个或两个以上的事务在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。
Innodb存储引擎采用wait-for graph(等待图)的方式来进行死锁检测。
# 锁升级
锁升级是指将当前锁的粒度降低。举例来说，数据库可以把一个表的 1000个行锁升级为一个页锁，或者将页锁升级为表锁。如果在数据库的设计中认为锁时一种稀有的资源，而且想避免锁的开销，那数据库中会频繁出现锁升级现象。
Innodb存储引擎不存在锁升级的问题。因为其不是根据每个记录来产生行锁的，相反，其根据每个事务访问的每个页对锁进行管理的，采用的是位图的方式。因此不管一个事务锁住页中一个记录还是多个记录，其开销通常都是一致的。
# MYSQL-Innodb下，update的并发是否会产生脏数据？
# 问题描述
语句1：update A set number=number+ 5 where id=1;
语句2：update A set number=number+ 7 where id=1;
2
假设这两条SQL语句同时被mysql执行，id=1的记录中number字段的原始值为 10，那么是否有可能出现这种情况：
语句1和2因为同时执行，他们得到的number的值都是10，都是在10的基础上分别加5和7，导致最终number被更新为15或17，而不是22？
# 正解
不会，并发执行时第一个update会持有id=1这行记录的排它锁（X锁），第二个update需要持有这个记录的排它锁的才能对他进行修改，
正常的话，第二个update会阻塞，直到第一个update提交成功，他才会获得这个排它锁，从而对数据进行修改。
# 小结
学习数据库锁时，在锁的分类中，不同分类方式锁所表示的含义是不一样的，不能混淆，比如，不能将行锁与共享锁做比较，不然会陷入死胡同，这是两种不同的概念。
| 锁的分类 | 相关的锁 |
|---|---|
| 锁模式分类 | 乐观锁、悲观锁 |
| 范围锁 | 行锁、表锁 |
| 属性锁 | 共享锁(S)、排他锁(X) |
| 状态锁 | 意向共享锁(IS)、意向排他锁(IX) |
| 算法锁 | 记录锁、间隙锁、Next-Key Lock |