MySQL：事务的隔离性

【参考文章】：数据库的事务特性及隔离级别

1. 事务的四大特性

1.1 原子性（Atomicity）

　　原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。

1.2 一致性（Consistency）

　　一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。

　　拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。

1.3 隔离性（Isolation）

　　隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。

　　即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。

1.4 持久性（Durability）

　　持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

2. 事务的隔离级别

　　事务的隔离级别有4种，由低到高分别为Read uncommitted 、Read committed 、Repeatable read 、Serializable 。而且，在事务的并发操作中可能会出现脏读，不可重复读，幻读。下面通过事例一一阐述它们的概念与联系。

2.1 Read uncommitted

　　读未提交，顾名思义，就是一个事务可以读取另一个未提交事务的数据。

　　事例：老板要给程序员发工资，程序员的工资是3.6万/月。但是发工资时老板不小心按错了数字，按成3.9万/月，该钱已经打到程序员的户口，但是事务还没有提交，就在这时，程序员去查看自己这个月的工资，发现比往常多了3千元，以为涨工资了非常高兴。但是老板及时发现了不对，马上回滚差点就提交了的事务，将数字改成3.6万再提交。

　　分析：实际程序员这个月的工资还是3.6万，但是程序员看到的是3.9万。他看到的是老板还没提交事务时的数据。这就是脏读。

　　那怎么解决脏读呢？Read committed！读提交，能解决脏读问题。

2.2 Read committed

　　读提交，顾名思义，就是一个事务要等另一个事务提交后才能读取数据。

　　事例：程序员拿着信用卡去享受生活（卡里当然是只有3.6万），当他埋单时（程序员事务开启），收费系统事先检测到他的卡里有3.6万，就在这个时候！！程序员的妻子要把钱全部转出充当家用，并提交。当收费系统准备扣款时，再检测卡里的金额，发现已经没钱了（第二次检测金额当然要等待妻子转出金额事务提交完）。程序员就会很郁闷，明明卡里是有钱的…

　　分析：这就是读提交，若有事务对数据进行更新（UPDATE）操作时，读操作事务要等待这个更新操作事务提交后才能读取数据，可以解决脏读问题。但在这个事例中，出现了一个事务范围内两个相同的查询却返回了不同数据，这就是不可重复读。

　　那怎么解决可能的不可重复读问题？Repeatable read ！

2.3 Repeatable read（mysql 默认隔离级别）

　　重复读，就是在开始读取数据（事务开启）时，不再允许修改操作，可以进行INSERT操作（幻读）

　　事例：程序员拿着信用卡去享受生活（卡里当然是只有3.6万），当他埋单时（事务开启，不允许其他事务的UPDATE修改操作），收费系统事先检测到他的卡里有3.6万。这个时候他的妻子不能转出金额了。接下来收费系统就可以扣款了。

　　分析：重复读可以解决不可重复读问题。写到这里，应该明白的一点就是，不可重复读对应的是修改，即UPDATE操作。但是可能还会有幻读问题。因为幻读问题对应的是插入INSERT操作，而不是UPDATE操作。

　　什么时候会出现幻读？

　　事例：程序员某一天去消费，花了2千元，然后他的妻子去查看他今天的消费记录（全表扫描FTS，妻子事务开启），看到确实是花了2千元，就在这个时候，程序员花了1万买了一部电脑，即新增INSERT了一条消费记录，并提交。当妻子打印程序员的消费记录清单时（妻子事务提交），发现花了1.2万元，似乎出现了幻觉，这就是幻读。

　　那怎么解决幻读问题？Serializable！

2.4 Serializable 序列化

　　Serializable 是最高的事务隔离级别，在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。

3. 事务的隔离性

3.1 事务的启动方式

1、用 begin 或 start transaction , rollback, commit来实现

begin 开始一个事务
rollback 事务回滚
commit 事务提交

2、直接用 SET AUTOCOMMIT 来改变 MySQL 的自动提交模式:

SET AUTOCOMMIT=0 禁止自动提交
SET AUTOCOMMIT=1 开启自动提交

3.2 事务的启动时机

　　1. begin / start transaction 并不是一个事务的起点，只有在执行到第一个操作 InnoDB 表语句，事务才真正启动；

　　2. start transaction with consistent snapshot 这个命令可以马上启动一个事务；　

　一致性视图：　

　　第一种启动方式，一致性视图是在执行第一个快照读语句时创建；

　　第二种启动方式，一致性视图是在执行命令时就创建的；

3.3 视图（read-view）

　　MySQL中有两个视图的概念：

　　1. 一个是 view，他是一个用查询语句定义的虚拟表，调用的时候执行查询语句并生成结果，创建视图的语法是 create view；

　　2. 一个是 InnoDB 实现 MVCC 时的一致性视图，用于支持读提交和可重复读的隔离级别；

在实现中，数据库创建一个视图，访问时以视图的逻辑结果为准。

　　读未提交：没有视图的概念，直接返回记录上的最新值；

　　读已提交：每个SQL语句执行时重新创建一个视图；

　　可重复读：事务启动时创建视图，整个事务期间查询操作都是使用这个视图；

　　串行化：直接加锁避免并行访问；

3.4 快照在MVCC中的工作原理

　　在可重复读的隔离界别下，事务在启动时拍了一个快照，这个快照是基于整个库的。

　　InnoDB 中每一个事务都有一个唯一的事务ID—transaction id，它在事务开始时向系统申请，按申请顺序严格递增。

　　每一行数据都有多个版本，每次事务更新数据都会生成一个新的数据版本，并把 transaction id 赋给数据版本的事务ID，记作 row trx_id，每个数据版本都有自己的 row trx_id。旧的数据版本可以通过当前版本和undo log 计算出来。

　　在MySQL中，每条记录在更新的时候同时会记录一条回滚操作，通过回滚操作可以得到上一个状态的值；

　　假设一条记录从1按顺序被改为2，3，4，则在不同时间启动的事务中，这条记录的值可能为1，2，3，4；

　　同一条记录可以存在多个版本就是数据库的多版本并发控制（MVCC），当系统中不存在比回滚日志更早的 read-view 时，就可以删除回滚日志了；

　　长事务意味着系统里面会存在很老的视图，这个事务提交之前，他可能用到的回滚日志都必须保留，这就导致大量空间的浪费；

3.5 更新逻辑

　　更新数据时都是先读后写，这个读指的是读当前的值（即最新的记录），称为当前读。

　　如果不读取最新的记录进行更新，而在历史版本上更新，则会丢失当前的更新操作。