数据库学习-事务
1 事务
1.1 什么是事务
事务可以理解为一个独立的工作单元, 在这个独立的工作单元中, 有一组操作，放在事务(独立工作单元)中的多个操作, 要么全部执行成功, 要么全部执行失败。
事务指的是满足 ACID 特性的一组操作，可以通过 Commit 提交一个事务，也可以使用 Rollback 进行回滚。
1.2 ACID（事务四大特性）
1.2.1 原子性（Atomicity）
事务被视为不可分割的最小单元，事务的所有操作要么全部提交成功，要么全部失败回滚。
对于一个事务来说, 不能只成功执行其中的一部分操作, 这就是事务的原子性。
回滚可以用日志来实现，日志记录着事务所执行的修改操作，在回滚时反向执行这些修改操作即可。
1.2.2 一致性（Consistency）
数据库在事务执行前后保持一致性状态。在一致性状态下，所有事务对一个数据的读取结果都是相同的。
比如一个转账的例子:A初始200 ，B初始300，A给B转100。
转账前一致性状态是：A(200元)，B(300元)
转账100元成功后一致性状态：A（100元），B(400元)
如果转账失败，一致性状态应该回滚到转账前的状态:A(200元)，B(300元)
1.2.3 隔离性（Isolation）
一个事务所做的修改在最终提交以前，对其它事务是不可见的。
隔离性是当多个用户并发访问数据库时，比如同时操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
事务有四种隔离级别(从低到高: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE)
即（未读提交、读提交、可重复读、序列化）
1.2.4 持久性（Durability）
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
可以通过数据库备份和恢复来实现，在系统发生崩溃时，使用备份的数据库进行数据恢复。
事务的 ACID 特性概念简单，但不是很好理解，主要是因为这几个特性不是一种平级关系：
- 只有满足一致性，事务的执行结果才是正确的。
- 在无并发的情况下，事务串行执行，隔离性一定能够满足。此时只要能满足原子性，就一定能满足一致性。
- 在并发的情况下，多个事务并行执行，事务不仅要满足原子性，还需要满足隔离性，才能满足一致性。
- 事务满足持久化是为了能应对数据库崩溃的情况。
MySQL 默认采用自动提交模式。也就是说，如果不显式使用START TRANSACTION语句来开始一个事务，那么每个查询都会被当做一个事务自动提交。
1.3 并发中可能出现的问题
1.3.1 丢失修改（Lost update）
如果多个线程操作，基于同一个查询结构对表中的记录进行修改，那么后修改的记录将会覆盖前面修改的记录，前面的修改就丢失掉了，这就叫做更新丢失。这是因为系统没有执行任何的锁操作，因此并发事务并没有被隔离开来。
T1 和 T2 两个事务都对一个数据进行修改，T1 先修改，T2 随后修改，T2 的修改覆盖了 T1 的修改。
1.3.2 读脏数据（Dirty Reads）
A事务读取B事务尚未提交的数据并在此基础上操作，而B事务执行回滚，那么A读取到的数据就是脏数据。
T1 修改一个数据，T2 随后读取这个数据。如果 T1 撤销了这次修改，那么 T2 读取的数据是脏数据。
1.3.3 不可重复读（Non-repeatable Reads）
如果在一个事务中多次读取同一个数据, 正好在两次读取之间, 另外一个事务确实已经完成了对该数据的修改并提交, 那问题就来了: 可能会出现多次读取结果不一致的现象。
T2 读取一个数据，T1 对该数据做了修改。如果 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不同。
1.3.4 幻影读
- 容易搞混不可重复读 和幻读 ，都是说两次读取数据不一致。
- 但不可重复读主要是说多次读取一条记录, 发现该记录中某些列值被修改过。
- 而幻读主要是说多次读取一个范围内的记录(包括直接查询所有记录结果或者做聚合统计), 发现结果不一致(标准档案一般指记录增多（一般来讲）, 记录的减少应该也算是幻读（猜测）)。
- 指两次执行同一条 select 语句会出现不同的结果，第二次读会增加一数据行，并没有说这两次执行是在同一个事务中。 通俗的讲，一个线程中的事务读取到了另外一个事务insert的数据。
T1 读取某个范围的数据，T2 在这个范围内插入新的数据，T1 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同。
1.4 封锁粒度
MySQL 中提供了两种封锁粒度：行级锁以及表级锁。
应该尽量只锁定需要修改的那部分数据，而不是所有的资源。锁定的数据量越少，发生锁争用的可能就越小，系统的并发程度就越高。
但是加锁需要消耗资源，锁的各种操作（包括获取锁、释放锁、以及检查锁状态）都会增加系统开销。因此封锁粒度越小，系统开销就越大。
总的来说：能少锁就少锁（减少系统开销）
1.5 封锁类型
1.5.1 读写锁
- 排它锁（Exclusive）,简写为X锁，又称为写锁。
- 共享锁（Shared），简写为S锁，又称为读锁。
有以下两个规定：
- 一个事务对数据对象A加了X锁，就可以对A读取和更新。加锁期间其它事务不能对A加任何锁。
- 一个事务对数据对象A加了S锁，可以对A进行读取操作，当不能进行更新操作。加锁期间其它事务能对A加S锁当不能加X锁。
锁的兼容关系如下（即只有S锁可以加S锁，其他情况都不可以）：
| - | X | S |
|---|---|---|
| X | × | × |
| S | × | √ |
1.5.2 意向锁
使用意向锁（Intention Locks）可以更容易地支持多粒度封锁。
意向锁存在原因：在存在行级锁和表级锁的情况下，事务 T 想要对表 A 加 X 锁，就需要先检测是否有其它事务对表 A 或者表 A 中的任意一行加了锁，那么就需要对表 A 的每一行都检测一次，这是非常耗时的。
意向锁在原来的 X/S 锁之上引入了 IX/IS，IX/IS 都是表锁，用来表示一个事务想要在表中的某个数据行上加 X 锁或 S 锁。有以下两个规定：
- 一个事务在获得某个数据行对象的 S 锁之前，必须先获得表的 IS 锁或者更强的锁；
- 一个事务在获得某个数据行对象的 X 锁之前，必须先获得表的 IX 锁。
意向锁作用：通过引入意向锁，事务 T 想要对表 A 加 X 锁，只需要先检测是否有其它事务对表 A 加了 X/IX/S/IS 锁，如果加了就表示有其它事务正在使用这个表或者表中某一行的锁，因此事务 T 加 X 锁失败。
各种锁的兼容关系如下：
| - | X | IX | S | IS |
|---|---|---|---|---|
| X | × | × | × | × |
| IX | × | √ | × | √ |
| S | × | × | √ | √ |
| IS | × | √ | √ | √ |
解释如下：
- 任意 IS/IX 锁之间都是兼容的，因为它们只是表示想要对表加锁，而不是真正加锁；
- S 锁只与 S 锁和 IS 锁兼容，也就是说事务 T 想要对数据行加 S 锁，其它事务可以已经获得对表或者表中的行的 S 锁。
1.6 隔离级别
事务的隔离级别有四种，由低到高依次为：
Read uncommited (未授权读取、读未提交)
Read commited（授权读取、读提交）
Repeatable read（可重复读取）
Serializable（序列化）
隔离级别高的数据库的可靠性高，但并发量低，而隔离级别低的数据库可靠性低，但并发量高，系统开销小。
1.6.1 未提交读（Read uncommited）
事务中的修改，即使没有提交，对其它事务也是可见的。
如果一个事务已经开始写数据，则另外一个事务则不允许同时进行写操作，但允许其他事务读此行数据。
该隔离级别可以通过**排他锁（X锁）**实现。这样就避免了更新丢失，却可能出现脏读。也就是说事务B读取到了事务A未提交的数据
ep:
一个售票系统，A和B是售票员，他们分别是两个不同窗口的员工，现在售票系统只剩下3张票，此时小明来A这里买3张票，小张来B买票，A查到余票还有就给接了订单，就要执行第三步的时候，B接到小张的请求查询有没有余票。B看到A卖出了3张票，于是拒绝卖票。但是A系统出了问题，第三步执行失败，数据库为保证原子性，数据进行了回滚，也就是说一张票都没卖出去。
总结:一个事务还没提交，而别的事务可以看到他其中修改的数据的后果，也就是脏读。
1.6.2 提交读（Read commited）
一个事务只能读取已经提交的事务所做的修改。换句话说，一个事务所做的修改在提交之前对其它事务是不可见的。
读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。
该隔离级别避免了脏读，但是却可能出现不可重复读。事务A事先读取了数据，事务B紧接更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变。
大多数数据库系统的默认隔离级别是READ CIMMITTED。
ep:
还是A和B销售员，余票4张，小明来A请求3张订票单，A受订单，要卖出3张票，上面的销售步骤执行中的时候，小张也来B那里买票，由于A的销售事务执行到一半，B事务没有看到A的事务执行，读到的票数是3，准备接受订单的时候，A的销售事务完成了，此时B的系统变成显示0张票，此时只能拒绝订单了。
总结:这就是A的事务执行到一半，而B看不到他执行的操作，所以看到的是旧数据，也就是不可重复读。
1.6.3 可重复读（Repeatable read）
保证在同一个事务中多次读取同样数据的结果是一样的。
可重复读是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。
在第一个事务中的两次读数据之间，即使第二个事务对数据进行修改，第一个事务两次读到的的数据是一样的。这样就发生了在一个事务内两次读到的数据是一样的，因此称为是可重复读。
读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。这样避免了不可重复读取和脏读，但是有时可能出现幻象读。（读取数据的事务）这可以通过“共享读锁”和“排他写锁”实现。
ep:
销售部门有规定，如果销售记录低于规定的值，要扣工资，此时经理在后端控制台查看了一下小明的销售记录，发现销售记录达不到规定的次数，心里暗喜，准备打印好销售清单，理直气壮和小明提出，没想到打印出来的时候发现销售清单里面销售数量增多了几条，刚刚好达到要求，气的经理撕了清单纸。原来是小明在就要打印的瞬间卖出了几张票，因此避过了减工资的血光之灾。
虽然读取同一条数据可以保证一致性，但是却不能保证没有插入新的数据,就是幻读。
1.6.4 串行化（Serializable）
强制事务串行执行。
提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。
如果仅仅通过行级锁是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。序列化是最高的事务隔离级别，同时代价也花费最高，性能很低，一般很少使用，在该级别下，事务顺序执行，不仅可以避免脏读、不可重复读，还避免了幻读。
对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读，而且具有较好的并发性能。尽管它会导致不可重复读、幻读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。
大多数数据库的默认级别就是Read committed，比如Sql Server , Oracle。MySQL的默认隔离级别就是Repeatable read。
1.7 多版本并发控制系统（MVCC）
多版本并发控制（Multi-Version Concurrency Control, MVCC）是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种具体方式，用于实现提交读和可重复读这两种隔离级别。而未提交读隔离级别总是读取最新的数据行，无需使用 MVCC。可串行化隔离级别需要对所有读取的行都加锁，单纯使用 MVCC 无法实现。
MVCC用于实现未读提交和可重复读这两个隔离级别，不能解决幻读。
1.7.1 版本号
- 系统版本号：是一个递增的数字，每开始一个新的事务，系统版本号就会自动递增。
- 事务版本号：事务开始时的系统版本号。
1.7.2 隐藏的列
MVCC 在每行记录后面都保存着两个隐藏的列，用来存储两个版本号：
- 创建版本号：指示创建一个数据行的快照时的系统版本号；
- 删除版本号：如果该快照的删除版本号大于当前事务版本号表示该快照有效，否则表示该快照已经被删除了。
1.7.3 Undo 日志
MVCC 使用到的快照存储在 Undo 日志中，该日志通过回滚指针把一个数据行（Record）的所有快照连接起来。
1.8 Next-Key Locks
Next-Key Locks 是 MySQL 的 InnoDB 存储引擎的一种锁实现。
MVCC 不能解决幻读的问题，Next-Key Locks 就是为了解决这个问题而存在的。在可重复读（REPEATABLE READ）隔离级别下，使用 MVCC + Next-Key Locks 可以解决幻读问题。
1.8.1 Record Locks
锁定一个记录上的索引，而不是记录本身。
如果表没有设置索引，InnoDB 会自动在主键上创建隐藏的聚簇索引，因此 Record Locks 依然可以使用。
###1.8.2 Gap Locks
锁定索引之间的间隙，但是不包含索引本身。例如当一个事务执行以下语句，其它事务就不能在 t.c 中插入 15。
SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;
1.8.3 Next-Key Locks
它是 Record Locks 和 Gap Locks 的结合，不仅锁定一个记录上的索引，也锁定索引之间的间隙。例如一个索引包含以下值：10, 11, 13, and 20，那么就需要锁定以下区间：
(negative infinity, 10]
(10, 11]
(11, 13]
(13, 20]
(20, positive infinity)
2 用自己的话总结事务
事务就是指满足ACID的特性的一组操作，要么全部做，要么全部不做。
说到事务那么就要说说事务的四大特性即：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。
- 原子性：事务要么全部做要么全部不做
- 一致性：事务在执行前后都保持一致性状态
- 隔离性：事务在修改之前对其他事务是不可见的
- 持久性：事务一旦提交那么修改就会永久保存到数据库中。
封锁类型主要分为读写锁和意向锁。
- 读写锁
- 读锁（S锁）：加了读锁只可以进行读操作，读锁上可以继续加读锁
- 写锁（X锁）：加了写锁可以进行读取、修改操作，写锁上不能添加其他的锁（包括写锁）
- 意向锁：使用意向锁（Intention Locks）可以更容易地支持多粒度封锁。
意向锁都是表锁，意向锁就像一个房管，不管用户是要使用整间房（整个表），还是使用房间的一部分（某行），其他用户等级要使用这个房间是都会先去房管那查询，这个房价是否被占用（是否加了意向锁），如果房间被占用了，房管就不会把这间房立即分给房客，而是等到原来的房客用完房间为止。
说到事务那么另外一个东西也要说说，那就是事务的隔离级别，在数据库中总共有四种隔离级别从低到高为：未提交度、提交度、可重复读、序列化。
- 未提交读：事务在未提交的时候对其他事务也是可见的（其他事务也是可以访问这个数据的）。
- 提交读：一个事务的修改在未提交前对其他事务是不可见的。
- 可重复读：保证在同一个事务中多次读取的结果是一样的。
- 序列化：事务只能一个接着一个地执行，但不能并发执行。
在Mysql中的隔离级别默认是使用的可重复读。
多版本并发控制（ MVCC）是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种具体方式，应用于实现提交读和可重复读这两种隔离级别，但是MVCC不能解决幻读的问题，MVCC+Next-Key Locks可以解决幻读问题。