03 | 事务隔离：为什么你改了我还看不见？

事务

保证一组数据库操作，要么全部成功，要么全部失败。在MySQL中，事务支持是在引擎层实现的。MyISAM引擎不支持事务，这也是MyISAM被InnoDB取代的重要原因之一。

隔离性与隔离级别

概念

ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性）

• 原子性(Automicity)：强调事务的不可分割性，同一个事务中的操作要么都成功，要么都失败；（不是事务都成功或失败，而是事务中包含的操作都成功或失败）
• 一致性(Consistent)：事务执行前后的数据完整性保持一致，举例：银行转账；
• 隔离性(Isolation)：一个事务执行的过程中，不应该受到其他事务的干扰；
• 持久性(Durable)：事务一旦结束，数据就持久存储到数据库中。
  脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）
• 脏读：A事务读到了B事务已更改但未提交的数据，并且在这个数据的基础上进行操作，如果此时B事务回滚，那么A事务发生脏读；
• 不可重复读：A事务读到了B事务数据，然后A事务再次读到了B事务已经提交的更改数据，导致两次查询结果不一致，所以不可重复读；
• 虚幻读：一般发生在计算统计数据的事务中，A事务读到了B事务的数据，然后A事务再次读到了B事务已经提交的插入数据，导致两次查询结果不一致，称为虚幻读。
  读未提交（read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（serializable ）
• 读未提交是指，一个事务还没提交时，它做的变更就能被别的事务看到。（脏读，不可重复读，虚读都可能发生）
• 读提交是指，一个事务提交之后，它做的变更才会被其他事务看到。（视图实现、避免脏读，但是不可重复读和虚读有可能发生）
• 可重复读是指，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。（视图实现、避免脏读和不可重复读，但是虚幻读有可能发生）
• 串行化，顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。（加锁实现、可以避免所以并发问题）
  假设数据表T中只有一列，其中一行的值为1，执行两个事务，
  
• 若隔离级别是“读未提交”， 则V1的值就是2。这时候事务B虽然还没有提交，但是结果已经被A看到了。因此，V2、V3也都是2。
• 若隔离级别是“读提交”，则V1是1，V2的值是2。事务B的更新在提交后才能被A看到。所以， V3的值也是2。
• 若隔离级别是“可重复读”，则V1、V2是1，V3是2。之所以V2还是1，遵循的就是这个要求：事务在执行期间看到的数据前后必须是一致的。
• 若隔离级别是“串行化”，则在事务B执行“将1改成2”的时候，会被锁住。直到事务A提交后，事务B才可以继续执行。所以从A的角度看， V1、V2值是1，V3的值是2。
  事务隔离的实现
  假设一个值从1被按顺序改成了2、3、4，在回滚日志里面就会有类似下面的记录。
  
  通过视图实现

问题：长事务存在的风险？

长事务意味着系统里面会存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间。

多版本并发控制（MVCC）

同一条记录在系统中可以存在多个版本

事务的启动方式

小结

你现在知道了系统里面应该避免长事务，如果你是业务开发负责人同时也是数据库负责人，你会有什么方案来避免出现或者处理这种情况呢？
答：