事务的四大特性
1.原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样，通过undo log实现。
2.持久性：事务处理结束后，数据库会把对数据的修改写到磁盘上，即便系统故障也不会丢失，保证了数据的持久性，通过redo logo来保证。
3.隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以让不同的事务看到不同的数据内容，防止多个事务并发执行导致数据不一致的问题。通过MVCC多版本并发控制实现，用到了ReadView读视图和undo log里面的历史版本链。
4.一致性：指事务操作前后，是从一个一致性的状态到另一个一致性的状态，它是由原子性，持久性，隔离性来共同保证一致性的。
- 原子性保证一致性：比如说银行转账，一方扣钱一方加钱，两条SQL属于一个事务，为了保证双方金额的一致性，两条SQL必须同时执行成功，或者就都不执行，这就保证了前后数据的一致性。
- 持久性保证一致性：比如我买了一个月以后回家的飞机票，一个月后买票的数据没了，但是我钱也花了，这就导致了数据的不一致。数据库要保证一个月后我买票的数据还在，就是通过持久性来保证的。（把买票的数据保存到磁盘上去）
- 隔离性保证一致性：如果没有隔离性，一致性同样得不到保证。比如在统计考试成绩的时候，一个事务里面，两条SQL，一条统计所有科目的平均分，一条统计语数英三门课的平均分。如果没有隔离性，一开始数学是60分，平均分统计完后，数学被其他事务改成了100分，后一条统计语数英三门课的平均分的时候，使用的数学成绩就和之前的不一样了，这就导致了不一致性。所以需要隔离性来保证事务的一致性。
事务的隔离级别
事务并行时会出现的问题
脏读：一个事务读取到了另一个事物修改后但是还没有提交的数据，这就发生了脏读。此时如果你发生回滚，那我读到的就是过期的数据。
不可重复读：在一个事务内，多次读取同一个数据，发现读取到的数据不一样，就发生了不可重复读的情况。事务A第一次读的是时候是100，然后事务B把这个值修改成了200，然后提交，事务A再读的时候就变成200了，重复读数据但是读到的却是不同的值。
幻读：一个事务内多次统计符合某个条件的记录数量，发现前后统计的数量不一致。比如事务A一开始统计不及格的人数有3个，然后事务B插入了一个不及格的人员信息，提交了事务，此时事务A再查不及格的记录数就变成4个了。
隔离级别
- 读未提交（read uncommitted），指一个事务还没提交时，它做的修改就能被其他事务看到；
- 读提交（read committed），指一个事务提交之后，它做的修改才能被其他事务看到；
- 可重复读（repeatable read），指一个事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，我可以重复读，不会读取到不一样的数据。MySQL InnoDB 引擎的默认隔离级别；
- 串行化（serializable ）；会对记录加上读写锁，在多个事务对这条记录进行读写操作时，如果发生了读写冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行；
隔离级别越高，越不容易出问题，但是相对的效率也会更低。
- 在「读未提交」隔离级别下，可能发生脏读、不可重复读和幻读现象；
- 在「读提交」隔离级别下，可能发生不可重复读和幻读现象，但是不可能发生脏读现象；
- 在「可重复读」隔离级别下，可能发生幻读现象，但是不可能脏读和不可重复读现象；
- 在「串行化」隔离级别下，脏读、不可重复读和幻读现象都不可能会发生。
如何实现隔离级别
- 读未提交：要读取到未提交的修改数据，所以直接读最新的数据就行。
- 串行化：通过加锁的方式实现
- 读提交和可重复读：通过MVCC（多版本并发控制）来实现的，用到了Undo log里面的历史版本链，还有ReadView读快照。（PS，准确一点还用到了几个隐藏字段，通过隐藏字段访问到历史版本链和最近修改记录的事务ID）
可重复读的是每次事务启动都生成一个ReadView，后续整个事务就使用这个ReadView。而读提交是每次读取数据的时候，会重新生成一个ReadView。
ReadView中有4个字段
- create_transaction_id，指创建该ReadView的事务id
- m_ids：当前活跃且未提交的事务列表
- min_transaction_id，当前活跃且未提交的事务列表中事务id的最小值
- max_transaction_id，创建ReadView时当前数据库中要分配给下一个事务的id。
然后每条记录里面还有两个隐藏字段，
- transaction_id表示最近一次修改该记录的事务id
- roll_pointer指针，指向undo log里面该记录的历史版本链，记录该记录被修改的不同版本，用链表的形式连接起来。
开始
当一个事务访问该记录的时候，首先获取最近修改该记录的事务id，就是transaction_id字段，然后获取到undo log历史版本链中的最新版本。
- 如果是自身，那当然允许访问
- 如果小于min_transaction_id，表示该版本在创建ReadView之前就创建了，固然允许访问。
- 如果大于max_transaction_id，表示该版本是在创建了ReadView之后才生成的，固然不允许访问，跳转到下一个历史版本
- 如果在min_transaction_id和max_transaction_id之间，则需要判断当前修改过该记录的事务有没有提交，提交了就可以访问，没有提交就不能访问。
可以查看transaction_id是否在m_ids列表中，如果在，说明该事务还在活跃，没有提交，就不能访问该版本；如果不在，说明该事务已经提交，固可以访问。
就经过这样一个过程，最终会找到当前事务可以访问的那个版本来访问。
