5. InnoDB的事务

InnoDB 系列文章目录

1.InnoDB的关键特性
2.InnoDB的存储结构
3.InnoDB的索引和算法
4.InnoDB的锁总结
5.InnoDB的事务

InnoDB的一个特性是支持事务，并且实现支持了四种隔离级别。

1.事务的目标：ACID

• 原子性
  原子性是指事务是不可分割的单位，如果其中一步失败了，前面执行成功的也要回滚。
• 隔离性
  隔离性是指，事务提交之前，变更的数据对其他事务不影响。
• 一致性
  一致性是指事务将数据的状态由上一个状态转换为下一个正确的状态。一致性容易和原子性混淆，即使实现了原子性也不一定能保证一致性，比如更新覆盖。
• 持久性
  持久性是指，事务提交之后，结果是永久性的，即使发生宕机，也能被恢复。

2.事务的实现

• 隔离性的实现
  隔离性是通过锁来实现的，在锁的那边文章里大概介绍了锁是如何实现隔离性的。
• 持久性的实现：redo日志
  redo日志记录了事务的操作，其作用是当缓冲池中数据刷新到磁盘失败时，通过redo日志重写执行事务的操作。保证了事务的持久性。
• 原子性的实现：undo日志
  uodo日志和redo日志相反，redo日志记录了事务操作的撤销动作，当事务失败时，通过undo日志，撤销已经成功的操作。
• 一致性的实现
  可以理解为，一致性的实现是由原子性，隔离性和持久性共同实现的。实际上，要真正的实现一致性，可能还要再业务逻辑上做保证。比如，为了防止更新被覆盖，除了是由串行化这种最高级别的隔离外，还可以使用乐观锁来实现。

3.事务语句

• start transaction|begin，开启事务，在存储过程只能使用start transaction
• commit 提交事务
• rollback 回滚事务
  如果在commit/rollback 加上work 会触发事务结束后的行为
  • completion_type=0时，无效果
  • completion_type=1时，表示马上开启一个相同隔离级别的事务
• savepoint + 保存点名称：保存一个点
• release savepoint +保存点名称：删除保存点
• rollback to [savepoint]+保存点名称:回滚到保存点位置，需要注意的是，这里并不会提交事务。
• set transaction ：设置隔离级别

4.事务隔离级别

• Read uncommit:可读未提交
  事务未提交的数据可以被其他事务读取到，会导致脏读，可能读错到错误的数据。
• Read commited：可读已提交
  只能读取到其他事务已经提交的数据，但是可能多次读会发现数据不一致，导致重复读问题。
• Repeatable Read：可重复读
  一直读取事务开始时的数据快照版本，保证了每次读取数据都是一致的。避免重复读问题。另外InnoDB使用了锁除了锁定数据行的更新，还锁定了查询的条件的插入删除，避免了幻读的问题。可重复读是InnoDB的默认事务隔离级别。
• Serializable：串行化
  所有的事务都串行化操作，避免所有的问题，不过会导致极大的效率问题，由于InnoDB在可重复读级别已经解决了幻读的问题，所以并不需要这个级别，除非有其他特殊的需求。

5.分布式事务

XA事务

mysql支持分布式事务，使用的是两段式提交。
第一阶段，所有事务都提交，并进入准备状态。
第二阶段，通知所有的事务是commit或者rollback，只有一个事务失败了，那么其他事务都需要rollback。

TCC 补充性事务

二段式提交的坏处式，如果事务链过长的化，会有大量的事务挂起，且必须使用串行化的隔离级别。几乎没有实际的应用。补充性事务并不是mysql实现的，而是另外一种分布式事务的实现方式。
补充性事务式每一个事务执行完毕后都直接提交，并锁定已经被消费的资源，比如冻结转账的金额，并提供一个回滚补充的方法。这样就不会因为事务挂起导致资源被锁定。而且每个一事务的关联粒度减少。
不过补充性的缺点是必须要写很多的补充性代码，而且有些事务并不能使用补充问题。

本地消息表

本地消息表是在TCC的基础上增加了消息队列和一个事务状态记录表，适用于时间比较长的事务。解耦了各个事务端。本地的事务提交后，只要记录事务的状态，并推送消息到消息队列，让下一个事务进行操作。定时检测事务状态的表，重新发送失败的事务。对于后续事务的失败，仍然要提供一个事务补偿。
本地消息表相比普通的补充性事务，解耦了各个事务。但是也导致了数据存在一定的时间内的不一致性。比如用户已经转账了，而被转账的人还没收到钱。但是最终经过一定的时间，数据还是会达到一致。也被称为最终一致性。