InnoDB引擎的事务与锁
一. 背景：事务和事务引发的问题
1. ACID
原子性：表示整个事务是不可分割的，要么都执行成功，要么都执行失败。
一致性：保证完整性约束没有被破坏。
隔离性： 事务不可见行，事务与事务之间分离不可见。
持久性:事务一旦提交，其结果就是永久性的，即使发生宕机，数据也是可以恢复的。
2. 事务的分类
1. 扁平事务
扁平事务是事务中最简单的一种，也是使用最频繁的，在扁平事务中，所有操作都处于同一层次，由BEGIN开始，COMMIT 或者ROLLBACK结束，其操作都是原子性的。
2. 带有保存点的扁平事务
在扁平事务的基础上，增加了保存点, 允许回滚到同一事务中较早的一个状态，因为在某些场景，放弃整个事务会浪费不必要的开销，对于扁平事务来说，隐式的增加了一个保存点，保存点用SAVE WORK函数建立，然后在事务中 只有这一个保存点， 保存点是一次递增的。
3. 链事务
可以看作是保存点模式的变种，当系统发生崩溃的时候，所有的保存点都会消失，因为保存点是**易失(volatile)的和非持久(persistent)**的，链事务的思想是：提交当前事务和开始下一个事务操作合并为一个原子操作，这意味这下一个事务是能看到上一个事务的处理结果的，如图 1-1：
图 1-1
4. 嵌套事务
嵌套事务是一个层次结构框架，InnoDB本事并不能很好的支持，因此需要依据前面三种事务，自己实现。
嵌套事务由一个顶层事务控制着各个层次的事务，被嵌套的事务被称为子事务，如图1-2：
图 1-2
(1). 嵌套事务是事务组成的一个树，子树既可以是嵌套事务，也可以是扁平事务。
(2). 处在叶子节点的事务是扁平事务。
(3). 叶子节点的深度可以不同。
(4). 子事务既可以提交也可以回滚，但不会立马生效，要等父事务提交，因此顶层事务是所有子事务的前置事务。
(5). 树中的任意个事务的回滚会引起它的子事务的回滚，故子事务仅保留A,C,I特性，不具有D特性。
分布式事务
通常是一个在分布式环境下运行的扁平事务，一般分为强一致性事务和柔一致性事务，比如基于XA的二阶段提交就属于强一致性事务，而基于MQ或者补偿机制的分布式事务属于柔一致性事务，基于BASE理论，强一致性事务要保证强一致性，而柔一致性事务保证的数据的最终一致性，这里不展开讨论分布式事务，在之后的文章会展开讨论分布式事务的常见实现和原理。
3. 事务的实现
事务的实现 一般依赖于Redo log 和 Undo Log。
1.Redo Log :
重做日志是用来实现事务的持久性，即事务ACID中的D。其由两部分组成：一个是内存中的重做日志缓存(redo log buffer)，它是易失的；二是重做日志文件(redo log file)，是持久的。
当事务提交的时候，必须先将该事务的所有日志写入到重做日志文件进行持久化，待提交的事务COMMIT才算完成。重做日志格式是基于页的，文件记录的是每一个事务操作的物理地址和偏移量，并不是记录的数据本身，当数据库宕机重启，就是依赖于重做日志恢复的。
这里需要注意的是 数据库的页一般都是16K大小，而计算机内存的页，一般是4K大小，为了保证Redo log在数据库和机器内存同步的时候，保证数据不会丢失和错误，会采用Double Write的思想，感兴趣的小伙伴可以去了解以下，这里不展开讨论。
2.Undo Log :
undo log就是帮我们解决事务回滚的功能，与redo log不同的是， undo log存放在数据库内部的一个特殊段中，位于共享表空间。
undo log分为 insert undo log 和 update undo log，insert 就是在插入数据的时候产生的 undo log ，只对自身事务可见，对其他事物不可见；而 update undo log记录的是对update 和 delete操作产生的 undo log，该log可能需要提供MVCC机制(下面会说到)，因此不能在事务提交的时候就删除，提交的时候放到 undo log链表，等待purge线程进行最后的删除。
3.事务引发的问题：
1.脏读：
指一个事务读取了另外一个事务未提交的数据。
| 事务一 | 事务二 |
|---|---|
| select * from user; //查出id为1的数据 | |
| insert into user(id,name) values(2,‘coco’); | |
| select * from user; //查出id为1 和 2 的数据 | |
| ROLLBACK | |
| select * from user; //查出id为1 |
2. 不可重复读：
在一个事务内读取表中的某一行数据，多次读取结果不同。（这个不一定是错误，只是某些场合不对）
| 事务一 | 事务二 |
|---|---|
| select * from user; //查出id=1,name=’leeco’的数据 | |
| update user set name=‘leeco2’ where id = 1; | |
| COMMIT | |
| select * from user; //查出id=1,name=’leeco’的数据 |
3.幻读：
是指在一个事务内读取到了别的事务插入的数据，导致前后读取不一致(更偏向于数量)
| 事务一 | 事务二 |
|---|---|
| select * from user; //查出id为1的数据 | |
| insert into user(id,name) values(2,‘coco’); | |
| COMMIT | |
| select * from user; //查出id为1 和 2 的数据 |
二. MVCC多版本并发控制（一致性非锁定读）
目的 : 解决一致性的非锁定读 成为快照读
图 2-1
该图直观的展示了非锁定读，之所以称为不锁定读，是因为不需要等待行X(排他)锁的释放。快照数据是指该行的之前的版本的数据，该实现是由undo段来完成的。而undo用来在事务中回滚数据，因为快照数据本身并没有额外的开销。此外，读取快照数据是不需要上锁的，因为没有事务需要对历史的数据进行修改操作。
因此，非锁定读大大提高了并发性。但是在不同的事务隔离级别下，读取的方式是不同的，在默认的可重复读(Repeatable Read)级别下，总是读取快照的开始时候的版本，而在读已提交(Read Committed)的级别下，总是读取最新的快照版本，因此读已提交会出现幻读的问题。
**MVCC解决快照读的幻读问题 : **针对与MVCC是否能解决幻读的问题，是存在争议的，绝大多数人认为是可以解决幻读的，少数人认为无法解决幻读，下例引发思考：
假设 ：现在user表有1条数据
| id | name |
|---|---|
| 1 | leeco |
现在做如下操作：
| 事务一 | 事务二 |
|---|---|
| select * from user; //查出id为1的数据 | |
| insert into user(id,name) values(2,‘coco’); | |
| select * from user; //查出id为1的数据 | |
| update user set name=‘coco’ where id=2; | |
| select * from user; //查出id为1 和 2 的数据 |
思考：这种情况到底算不算幻读问题?
三. 行锁算法（一致性锁定读）
锁算法都是基于索引的,且锁的就是索引本身，而InnoDB默认使用的是next-key Lock
以下内容 非特殊情况 都是基于默认的可重复读的隔离级别展开说明!
| 共享锁(S) | 排他锁(X) | |
|---|---|---|
| 共享锁(S) | 兼容 | 不兼容 |
| 排他锁(X) | 不兼容 | 不兼容 |
一致性锁定读，是显式在SELECT的时候加锁以保证数据逻辑的一致性，而这要求对操作行进行加锁语法
SELECT … FOR UPDATE; 加一个X锁，此时其他事务不能做任何操作
SELECT … LOCK IN SHARE MODE；加一个S锁，此时其他事务可以加S锁，但是加X锁会被阻塞
1. 间隙锁(Gap Lcok)
锁定一定的范围，但不包含本身 (左开右开)
2. 临键锁(Next-Key Lock)
锁定一定的范围，并且锁住本身 即GapLock + Record Lock (左开右闭)
3. 记录锁(Record Lock)
锁定单行记录
比如数据记录 1，5，9，Record Lock锁住的就是1，5，9，Gap Lcok锁住的是(-∞,1),(1,5),(5,9),(9,+∞)，
Next-Key Lock锁住的是 (-∞,1], (1,5], (5,9], (9,+∞]
注意了，这里仅针对RR隔离级别，对于RC隔离级除了外键约束和唯一性约束会加间隙锁，没有间隙锁，自然也就没有了临键锁，所以RC级别下加的行锁都是记录锁，没有命中记录则不加锁，所以RC级别是没有解决幻读问题的。
那么这三种锁分别在什么时候生效呢，首先，行锁是基于索引的，InnoDB默认是的采用Next-Key Lock锁算法, 例如上例，
当 SELECT … WHERE ID = 5; 的时候，若ID非索引，则退化成表锁；如果ID是辅助索引，则会对前一个区域使用临键锁，即锁住了 (1,5] ，然后对下一个区域使用间隙锁，即锁住了(5,9)，总结就是锁住了(1,9); 只有当ID是非空唯一索引的时候，会升级为记录锁(Record Lock), 只锁住ID=5的这一行记录的索引。
注意：虽然ID是非空唯一索引，但是当查询条件是范围查询的时候 也会退化为临键锁。
例如上例中，select * from id > 6; 此时 只能查出来ID=9的数据，然后添加一条ID=10的数据，如果没有临键锁，则下次查询会查出来ID=9和ID=10两条数据，就出现了幻读。而真是情况是：因为是范围查找，InnoDB采用临键锁，此时会对(6,9]和(9,+∞)范围进行加锁, 此时插入ID=10的数据会被阻塞，所以不会出现幻读.
因此 在当前读的环境下 临键锁解决了幻读问题。
四. 死锁问题
死锁 是指两个或两个以上的事务在执行过程中，因为抢夺资源而造成的一种互相等待的现象。
解决死锁的方式最简单的是超时，当超过等待时间 则进行回滚；
还有一种普遍的方式就是采用**wait-for graph(**等待图),要求数据库保存两种信息: 锁的信息链表，事务等待链表，
通过上述链表可以构造出一张图，如存在回路，则表示存在死锁问题，如图4-1：
图4-1
五. 总结：
1. InnoDB 通过 MVCC 和 NEXT-KEY Locks，解决了在可重复读的事务隔离级别下出现幻读的问题。
2. 即使InnoDB默认是采用可重复读的事务隔离级别，但是正是由于MVCC和临键锁的存在，解决了幻读的问题，因此已经达到了串行化的隔离级别。
本文地址：https://blog.csdn.net/shuchuntang2729/article/details/107922232