数据库事务(Transaction)与锁(Locking)详解图析

一、事务

---

事务（Transaction）是由一系列对系统中数据进⾏访问与更新的操作所组成的⼀个程序执行逻辑单元。

注：中止（abort）：表示事务未成功结束，撤消事务的所有操作。
数据库应用程序通常通过事务而不是单个操作访问数据库。例如，大型数据库和百万并发用户：银行、双十一、订票系统等。

结合程序语言的角度通过实例理解一下事务：
插入（INSERT）、选择（SELECT）、更新（UPDATE）、删除（DELETE）
开始（BEGIN）、提交（COMMIT）、中止（ABORT）/ 回滚（ROLLBACK）等;

BEGIN TRANSACTION
SELECT balance FROM summary WHERE name = `张三';
UPDATE summary SET balance = balance-500 WHERE name=`张三';
SELECT balance FROM summary WHERE name = `李四';
UPDATE summary SET balance = balance+500 WHERE name = `李四';
COMMIT

典型的银行转账张三转给李四张三-500，李四+500

内部进程级别：操作对象为数据库数据(表行列内存单元)。
读（read）、写（write）开始（begin）、提交（commit）
中止（abort）：表示事务未成功结束，撤消事务的所有操作

步骤	Transactions
1	read（张三）
2	write（张三） (张三:= 张三- 500)
3	read（李四）
4	write（李四） (李四:= 李四+ 500)
5	commit

---

带着问题学习事务

1. 事务的语法
2. 事务的特性
3. 事务的并发问题
4. 事务的隔离级别
5. 不同隔离级别的锁的情况了解
6. 隐式提交(了解)

结合下面的事务图了解：

1.1 事务的语法

1. start transaction; begin;
2. commit; 提交 使得当前的修改确认
3. rollback; 回滚 使得当前的修改被放弃

1.2 事务的ACID特性

1. 原⼦性（Atomicity）
   事务的原⼦性是指事务必须是⼀个原子的操作序列单元。事务中包含的各项操作在⼀次执⾏过程中，只允许出现两种状态之一。
   （1）全部执行成功
   （2）全部执行失败
   事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执⾏过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发⽣一样。也就是说事务是⼀个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。
2. ⼀致性（Consistency）
   事务的一致性是指事务的执⾏不能破坏数据库数据的完整性和一致性，一个事务在执⾏之前和执行之后，数据库都必须处以⼀致性状态。
   比如：如果从A账户转账到B账户，不可能因为A账户扣了钱，⽽B账户没有加钱。
3. 隔离性（Isolation）
   事务的隔离性是指在并发环境中，并发的事务是互相隔离的。也就是说，不同的事务并发操作相同的数据时，每个事务都有各自完整的数据空间。⼀个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务是不能互相干扰的。隔离性分4个级别
4. 持久性（Duration）
   事务的持久性是指事务⼀旦提交后，数据库中的数据必须被永久的保存下来。即使服务器系统崩溃或服务器宕机等故障。只要数据库重新启动，那么一定能够将其恢复到事务成功结束后的状态。

1.3 事务的并发问题

• 脏读：读取到了没有提交的数据, 事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据。
  

• 不可重复读：同⼀条命令返回不同的结果集（更新）.事务 A 多次读取同一数据，事务 B 在事务A 多次读取的过程中，对数据做了更新并提交，导致事务A多次读取同一数据时，结果不一致。
  

• 幻读：重复查询的过程中，数据就发⽣了量的变化（insert,delete）。
  

1.4 事务隔离级别

事务隔离级别	脏读	不可重复读	幻读
读未提交（READ_UNCOMMITTED）	允许	允许	允许
读已提交（READ_COMMITTED）	禁止	允许	允许
可重复读（REPEATABLE_READ）	禁止	禁止	可能会
顺序读（SERIALIZABLE）	禁止	禁止	禁止

4种事务隔离级别从上往下，级别越高，并发性越差，安全性就越来越高。 ⼀般数据默认级别是读以提交或可重复读

• 读未提交（READ_UNCOMMITTED）
  读未提交，该隔离级别允许脏读取，其隔离级别是最低的。换句话说，如果一个事务正在处理理某一数据，并对其进⾏了更新，但同时尚未完成事务，因此还没有提交事务；而以此同时，允许另一个事务也能够访问该数据。
  脏读示例：
  在事务A和事务B同时执行时可能会出现如下场景：

时间	事务A（存储）	事务B（取款）
T1	开始事务	—
T2	—	开始事务
T3	—	查询余额（1000元）
T4	—	取出1000元（余额0元）
T5	查询余额（余额0元）	—
T6	—	撤销事务（余额恢复1000元）
T7	存入500元	—
T8	提交事务	—

余额应该为1500元才对。请看T5时间点，事务A此时查询的余额为0，这个数据就是脏数据，他是事务B造成的，很明显是事务没有进行隔离造成的。

---

• 读已提交（READ_COMMITTED）
  读已提交是不同的事务执行的时候只能获取到已经提交的数据。 这样就不会出现上面的脏读的情况了。但是在同一个事务中执行同一个读取,结果不一致不可重复读示例
  可是解决了脏读问题，但是还是解决不了可重复读问题。

时间	事务A（存储）	事务B（取款）
T1	开始事务	—
T2	—	开始事务
T3	—	查询余额（1000元）
T4	查询余额（余额1000元）	—
T5	—	取出1000元（余额0元）
T6	—	提交事务
T7	查询余额（余额0元）	—
T8	提交事务	—

事务A其实除了查询两次以外，其它什么事情都没做，结果钱就从1000变成0了，这就是不不可重复读的问题。

---

• 可重复读（REPEATABLE_READ）
  可重复读就是保证在事务处理过程中，多次读取同一个数据时，该数据的值和事务开始时刻是一致的。因此该事务级别限制了不可重复读和脏读，但是有可能出现幻读的数据。
  幻读就是指同样的事务操作，在前后两个时间段内执行对同一个数据项的读取，可能出现不一致的结果。诡异的更新事件。

时间	事务A（存储）	事务B（取款）
T1	开始事务	—
T2	查询当前所有数据	开始事务
T3	—	插入一条数据
T4	查询当前所有数据	提交事务
T5	进行范围修改	—
T6	查询当前所有数据	—
T7	提交事务	—

可以看出在T3中事务B插入了一条数据，重复查询的过程中，数据就发⽣了量的变化（insert,delete）。

• 顺序读（SERIALIZABLE）
  顺序读是最严格的事务隔离级别。它要求所有的事务排队顺序执⾏，即事务只能一个接一个地处理，不能并发。

二、 锁（Locking）

先了解锁的概念

2.1 锁的概念与用法

锁是一种用于并发控制的技术，可保证事务的隔离性。锁在数据库中一般作用在对象上，如文件、表、记录、页等。

锁的用法分成两类：

• 共享锁：多个事务可以同时获取它。
• 互斥锁：只有一个事务可以获得它，导致其他试图获取它的事务等待。持有锁的事务完成后，它释放锁，允许一个等待的事务获取锁。

---

2.2 不同的隔离级别的锁的情况

1. 读未提交（RU）: 有行级的锁，没有间隙锁。它与RC的区别是能够查询到未提交的数据。
2. 读已提交（RC）：有行级的锁，没有间隙锁，读不到没有提交的数据。
3. 可重复读（RR）：有行级的锁，也有间隙锁，每次读取的数据都是一样的，并且没有幻读的情况。
4. 序列化（S）：有行级锁，也有间隙锁，读表的时候，就已经上锁了

---

2.3 行锁

行锁就是针对数据库中表的行记录的锁，这很好理解，比如事务 A 更新了一行，而这时候，事务 B 也要更新一行，则必须等事务 A 的操作完成后才能更新。
注：MyISAM 不支持行锁，InnoDB 是支持行锁的

---

2.4 两阶段锁（2PL：Two-phase Locking）

举一个实例，假设有book表，有bookid和name字段，在下面的操作中，事务 B 的 update 语句执行时，会是什么现象呢

这个问题的结论取决于事务 A 执行完前两条语句后，持有哪些锁，以及在什么时候释放。
实际上，事务 A 持有两个记录的行锁，都是在 commit 的时候才释放的，所以事务 B 的 update 就会被阻塞，直到事务 A 执行 commit 之后，事务 B 才能被继续执行。也就是说，在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，需要等事务结束时才释放，这就是两阶段锁协议，分为加锁阶段和解锁阶段，所有的 lock 操作都在 unlock 操作之后。

---

2.5 两阶段锁的优化

假设你负责实现一个医院缴费管理，患者A要在医院缴费，需要涉及以下操作：

语句1：扣除患者A 账户余额

语句2：增加医院总账户余额

语句3：记录一条交易日志

也就是说，完成这次交易，需要 update 两条记录，并 insert 一条记录。当然为了保证交易的原子性，我们需要这三个操作放在一个事务中。与此同时，还有患者B也需要在医院缴费，那么你会怎样安排这三个语句在事务中的顺序呢？

不管哪个患者都需要的步骤就是语句2，增加医院总账户余额，这两个事务都需要进行这个操作，根据两阶段协议，不论怎么安排语句，所有的操作需要的行锁都是在事务提交的时候才释放的，要想使行锁在事务中不会停留太长时间，最大程度的减少了事务之间的锁等待，节约资源，就应该把语句2直接放在最后如下图：

2.6 死锁

两个或多个事务的相互阻塞
如下图所示，事务 A 在等待事务 B 释放 id = 2 的行锁，而事务 B 在等待 事务 A 释放 id = 1 的行锁，事务 A 和事务 B 在互相等待对方的资源释放，就是进入了死锁状态。

死锁不是数据库自身的问题，我们无法通过优化数据库配置来解决或者避免死锁，只能通过修改应用程序来解决。简单来说，我们应该在程序中按照相同的顺序修改数据，避免产生相互等待资源的情况发生。
不过，我们在实际应用中可能无法完全按照相同顺序修改数据。如果出现了不可避免的死锁情况，另一种解决方法就是捕获系统返回的死锁异常并在程序中加入重试机制。