原博文有图，做得很漂亮～
浅谈数据库并发控制 - 锁和 MVCC
常见的三种并发控制机制：
悲观锁
乐观锁
多版本并发控制 MVCC(Multi-Version Concurrency Control)
1.悲观锁
对数据被修改持悲观的态度，在数据处理的过程中都会被锁定，以此来解决竞争的问题
1.1读写锁
读锁：只可以进行读操作，多个事务共享
写锁：可以对数据进行读和写操作，互斥锁
1.2两阶段锁协议（2PL）
是一种能够保证事务可串行化的协议，它将事务的获取锁和释放锁划分成了增长（Growing）和缩减（Shrinking）两个不同的阶段
增长阶段：一个事务可以获得锁但不能释放锁
缩减阶段：一个事务可以释放锁但不能获得新的锁
两个变种：
Strict 2PL：事务持有的互斥锁必须在提交后再释放；
Rigorous 2PL：事务持有的所有锁必须在提交后释放；
1.3死锁
解决死锁大体来看有两种办法：
从源头杜绝死锁的产生和出现
允许系统进入死锁的状态，但在出现死锁时能及时发现并进行恢复
预防死锁
-
保证事务之间的等待不会出现环：事务之间的等待图应该是一张有向无环图，没有循环等待的情况或者保证一个事务中想要获得的所有资源都在事务开始时以原子的方式被锁定，所有的资源要么被锁定要么都不被锁定
问题：在事务一开始时很难判断哪些资源是需要锁定的
问题：一些很晚才会用到的数据被提前锁定，数据的利用率与事务的并发率也非常的低
-
抢占加事务回滚：事务开始执行时会先获得一个时间戳，数据库程序会根据事务的时间戳决定事务应该等待还是回滚
wait-die：先执行的事务等待后执行的事务释放锁
wound-wait：后执行的事务回滚并等待先执行的事务释放锁
问题：造成不必要的事务回滚，带来一定的性能损失
死锁检测和恢复
数据库程序需要维护数据和事务之间的引用信息，同时也需要提供一个用于判断当前数据库是否进入死锁状态的算法，最后需要在死锁发生时提供合适的策略及时恢复
恢复：选择整个环中一个事务(牺牲者)进行回滚
- 选择牺牲者的原则：最小化代价。综合考虑事务已经计算的时间、使用的数据行以及涉及的事务等因素
- 全部回滚or部分回滚(回滚到某个检查点上)
- 可能某些任务多次被选择成为牺牲品，造成饥饿（Starvation），我们需要保证事务会在有穷的时间内执行，所以要在选择牺牲品时将时间戳加入考虑的范围
1.4锁的粒度与意向锁
数据库锁、表级锁、行级锁 加锁：在当前节点加显示锁（explicit），在其所有子节点加隐式锁（implicit）
意向锁
给子节点加锁时，会先给所有的父节点加对应的意向锁
意向共享锁（intention shared lock, IS）：事务有意向对表中的某些行加共享锁（S锁）
意向排他锁（intention exclusive lock, IX）：事务有意向对表中的某些行加排他锁（X锁）
意向锁是有数据引擎自己维护的，用户无法手动操作意向锁，在为数据行加共享/排他锁之前，InooDB 会先获取该数据行所在数据表的对应意向锁
A.意向锁之间、B.意向锁和行级锁之间，是完全不冲突的，只是用来帮助父节点快速判断是否可以对该节点进行加锁
| 意向共享锁（IS） | 意向排他锁（IX） | |
|---|---|---|
| 意向共享锁（IS） | 兼容 | 兼容 |
| 意向排他锁（IX） | 兼容 | 兼容 |
但意向锁会与普通的表级排他/共享锁互斥。注意S和X都是表级锁，不是行级锁。意向锁和行级锁是不互斥的！
| 意向共享锁（IS） | 意向排他锁（IX） | |
|---|---|---|
| 表级共享锁（S） | 兼容 | 互斥 |
| 表级排他锁（X） | 互斥 | 互斥 |
2.乐观锁
不是真正的锁，只是一种并发控制的思想
2.1基于时间戳的并发控制
保证事务并行执行的顺序与事务按照时间戳串行执行的效果完全相同
2.2基于验证的并发控制(乐观锁)
根据事务的只读或者更新将所有事务的执行分为两到三个阶段：
read：执行事务中的全部读操作和写操作，写后的值存到临时变量
validation (-> abort)：检查当前的改动是否合法（如果不合法则被终止）
write：如果合法进行写操作，写入数据库
- 需要知道一个事务不同阶段的发生时间，包括事务开始时间、验证阶段的开始时间以及写阶段的结束时间；
- 通过这三个时间戳，我们可以保证任意冲突的事务不会同时写入数据库，一旦由一个事务完成了验证阶段就会立即写入，其他读取了相同数据的事务就会回滚重新执行
- 乐观锁假定所有的事务在最终都会通过验证阶段并且执行成功，而锁机制和基于时间戳排序的协议是悲观的，因为它们会在发生冲突时强制事务进行等待或者回滚
