文章目录
- 1.事务
- 1.什么是事务
- 2.事务的特性
- 3.并发事务带来的问题
- 2.事务的隔离级别
- 3.MySQL默认隔离级别
- 4.MySQL锁机制
- 1.共享/排它锁(Shared and Exclusive Locks)
- 2.意向锁(Intention Locks)
- 3.记录锁(Record Locks)
- 4.间隙锁(Gap Locks)
- 5.临键锁(Next-key Locks)
- 6.插入意向锁(Insert Intention Locks)
- 7.自增锁(Auto-inc Locks)
- 5.事务的传播特性
1.事务
1.什么是事务
事务是逻辑上的⼀组操作，要么都执⾏，要么都不执⾏。
2.事务的特性
- 原⼦性（Atomicity）： 事务是最⼩的执⾏单位，不允许分割。事务的原⼦性确保动作要么全部完成，要么完全不起作⽤；
- ⼀致性（Consistency）： 执⾏事务前后，数据保持⼀致，多个事务对同⼀个数据读取的结果是相同的；
- 隔离性（Isolation）： 并发访问数据库时，⼀个⽤户的事务不被其他事务所⼲扰，各并发事务之间数据库是独⽴的；
- 持久性（Durability）： ⼀个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发⽣故障也不应该对其有任何影响。
3.并发事务带来的问题
在典型的应⽤程序中，多个事务并发运⾏，经常会操作相同的数据来完成各⾃的任务（多个⽤户对同⼀数据进⾏操作）。并发虽然是必须的，但可能会导致以下的问题。
脏读（Dirty read）: 当⼀个事务正在访问数据并且对数据进⾏了修改，⽽这种修改还没有提交到数据库中，这时另外⼀个事务也访问了这个数据，然后使⽤了这个数据。因为这个数据是还没有提交的数据，那么另外⼀个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。
丢失修改（Lost to modify）: 指在⼀个事务读取⼀个数据时，另外⼀个事务也访问了该数据，那么在第⼀个事务中修改了这个数据后，第⼆个事务也修改了这个数据。这样第⼀个事务内的修改结果就被丢失，因此称为丢失修改。 例如：事务1读取某表中的数据A=20，事务2也读取A=20，事务1修改A=A-1，事务2也修改A=A-1，最终结果A=19，事务1的修改被丢失。
不可重复读（Unrepeatableread）: 指在⼀个事务内多次读同⼀数据。在这个事务还没有结束时，另⼀个事务也访问该数据。那么，在第⼀个事务中的两次读数据之间，由于第⼆个事务的修改导致第⼀个事务两次读取的数据可能不太⼀样。这就发⽣了在⼀个事务内两次读到的数据是不⼀样的情况，因此称为不可重复读。
幻读（Phantom read）: 幻读与不可重复读类似。它发⽣在⼀个事务（T1）读取了⼏⾏数据，接着另⼀个并发事务（T2）插⼊了⼀些数据时。在随后的查询中，第⼀个事务（T1）就会发现多了⼀些原本不存在的记录，就好像发⽣了幻觉⼀样，所以称为幻读。
2.事务的隔离级别
为了支持事务，Innbodb引入了下面几个概念：
redo log
redo log就是保存执行的SQL语句到一个指定的Log文件，当Mysql执行recovery时重新执行redo log记录的SQL操作即可。当客户端执行每条SQL（更新语句）时，redo log会被首先写入log buffer；当客户端执行COMMIT命令时，log buffer中的内容会被视情况刷新到磁盘。redo log在磁盘上作为一个独立的文件存在，即Innodb的log文件。
undo log
与redo log相反，undo log是为回滚而用，具体内容就是copy事务前的数据库内容（行）到undo buffer，在适合的时间把undo buffer中的内容刷新到磁盘。undo buffer与redo buffer一样，也是环形缓冲，但当缓冲满的时候，undo buffer中的内容会也会被刷新到磁盘；与redo log不同的是，磁盘上不存在单独的undo log文件，所有的undo log均存放在主ibd数据文件中（表空间），即使客户端设置了每表一个数据文件也是如此。
rollback segment
回滚段这个概念来自Oracle的事物模型，在Innodb中，undo log被划分为多个段，具体某行的undo log就保存在某个段中，称为回滚段。可以认为undo log和回滚段是同一意思。
SQL 标准定义了四个隔离级别：
READ-UNCOMMITTED(读取未提交)： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
READ-COMMITTED(读取已提交)： 允许读取并发事务已经提交的数据，可以阻⽌脏读，但是幻读或不可重复读仍有可能发⽣。
REPEATABLE-READ(可重复读)： 对同⼀字段的多次读取结果都是⼀致的，除⾮数据是被本身事务⾃⼰所修改，可以阻⽌脏读和不可重复读，但幻读仍有可能发⽣。
SERIALIZABLE(可串⾏化)： 最⾼的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执⾏，这样事务之间就完全不可能产⽣⼲扰，也就是说，该级别可以防⽌脏读、不可重复读以及幻读。
3.MySQL默认隔离级别
MySQL InnoDB 存储引擎的默认⽀持的隔离级别是 REPEATABLE-READ（可重读）
与 SQL 标准不同的地⽅在于 InnoDB 存储引擎在 REPEATABLE-READ（可重读） 事务隔离级别下使⽤的是Next-Key Lock 锁算法，因此可以避免幻读的产⽣，这与其他数据库系统(如SQL Server) 是不同的。所以说InnoDB 存储引擎的默认⽀持的隔离级别是 REPEATABLE-READ（可重读） 已经可以完全保证事务的隔离性要求，即达到了 SQL标准的 SERIALIZABLE(可串⾏化) 隔离级别。因为隔离级别越低，事务请求的锁越少，所以⼤部分数据库系统的隔离级别都是 READCOMMITTED(读取提交内容) ，但是你要知道的是InnoDB 存储引擎默认使⽤ REPEAaTABLE-READ（可重读） 并不会有任何性能损失。
4.MySQL锁机制
1.共享/排它锁(Shared and Exclusive Locks)
共享锁（Share Locks，记为S锁），读取数据时加S锁
排他锁（eXclusive Locks，记为X锁），修改数据时加X锁
使用的语义为：
共享锁之间不互斥，简记为：读读可以并行
排他锁与任何锁互斥，简记为：写读，写写不可以并行
可以看到，一旦写数据的任务没有完成，数据是不能被其他任务读取的，这对并发度有较大的影响。对应到数据库，可以理解为，写事务没有提交，读相关数据的select也会被阻塞，这里的select是指加了锁的，普通的select仍然可以读到数据(快照读)。
2.意向锁(Intention Locks)
InnoDB为了支持多粒度锁机制(multiple granularity locking)，即允许行级锁与表级锁共存，而引入了意向锁(intention locks)。意向锁是指，未来的某个时刻，事务可能要加共享/排它锁了，先提前声明一个意向。
意向锁是一个表级别的锁(table-level locking)；
意向锁又分为：
意向共享锁(intention shared lock, IS)，它预示着，事务有意向对表中的某些行加共享S锁；
意向排它锁(intention exclusive lock, IX)，它预示着，事务有意向对表中的某些行加排它X锁；
事务要获得某些行的S/X锁，必须先获得表对应的IS/IX锁，意向锁仅仅表明意向，意向锁之间相互兼容，兼容互斥表如下：
IS | IX | |
IS | 兼容 | 兼容 |
IX | 兼容 | 兼容 |
虽然意向锁之间互相兼容，但是它与共享锁/排它锁互斥，其兼容互斥表如下:
S | X | |
IS | 兼容 | 互斥 |
IX | 互斥 | 互斥 |
3.记录锁(Record Locks)
记录锁，它封锁索引记录，例如(其中id为pk)：
4.间隙锁(Gap Locks)
间隙锁，它封锁索引记录中的间隔，或者第一条索引记录之前的范围，又或者最后一条索引记录之后的范围
5.临键锁(Next-key Locks)
临键锁，是记录锁与间隙锁的组合，它的封锁范围，既包含索引记录，又包含索引区间。
6.插入意向锁(Insert Intention Locks)
对已有数据行的修改与删除，必须加强互斥锁(X锁)，那么对于数据的插入，是否还需要加这么强的锁，来实施互斥呢？插入意向锁，孕育而生。
插入意向锁，是间隙锁(Gap Locks)的一种（所以，也是实施在索引上的），它是专门针对insert操作的。多个事务，在同一个索引，同一个范围区间插入记录时，如果插入的位置不冲突，不会阻塞彼此。
7.自增锁(Auto-inc Locks)
自增锁是一种特殊的表级别锁（table-level lock），专门针对事务插入AUTO_INCREMENT类型的列。最简单的情况，如果一个事务正在往表中插入记录，所有其他事务的插入必须等待，以便第一个事务插入的行，是连续的主键值。
5.事务的传播特性
REQUIRED：默认的传播特性，业务方法需要在一个事务中运行，如果一个方法已经处在一个事务中那么就加入到这个事务中，否则就会创建一个事务。
NEVER:指定的业务方法绝对不能在事务范围内运行，如果业务方法在某个事务中执行，就会抛异常，只有业务方法没有任何事务才正常执行。
MANDATORY:该属性指定业务方法只能在一个已经存在的事务中执行，业务方法不能自己发起自己的事务，如果业务方法不存在事务，容器就抛异常。
SUPPORTS:如果业务方法中已经在某个事务中被调用，则方法就称为事务的一部分，如果外部业务方法没有开启事务，supports该方法也会在没有事务的环境中执行。
NOT_SUPPORTED：如果该业务方法在一个事务中被调用，那么当前的事务会被挂起，执行该业务方法，方法执行完毕唤醒被挂起的事务，如果业务方法不在一个事务中执行，该方法也不会开事务。不管是否在有无事务的环境中执行都不开启事务。
REQUIRES_NEW:不管是否存在事务，业务方法总会自己开启一个事务，如果在已有事务的环境中调用，已有事务会被挂起，新的事务会被创建，直到业务方法调用结束，已有事务才被唤醒
NESTED:如果业务方法在一个事务中执行，就在这个事务中嵌套，如果没有事务按着required执行，开启单独的事务，这种事务有多个事务的保存点，内部事务的回滚对外部事务没有影响
