1.什么是事务？
数据库的事务是指一组sql语句访问各种数据项的数据库逻辑处理单元，在这组 SQL 操作中，要么全部执行成功，要么全部执行失败。

  • 举个经典的例子就是转账，事务 A要进行转账，那么，转出的账号要扣钱，转入的账号要加钱，这两操作要么同时执行成功，要么都全部执行失败。为得就是确保数据的一致性。

事务想要做到什么效果？

  • 可靠性：数据库要保证当insert或update操作时抛异常，或者数据库crash的时候需要保障数据的操作前后的一致，想要做到这个，我需要知道我修改之前和修改之后的状态，所以就有了undo log和redo log。

  • 并发处理：也就是说当多个并发请求过来，并且其中有一个请求是对数据修改操作的时候会有影响，为了避免读到脏数据，所以需要对事务之间的读写进行隔离，至于隔离到啥程度得看业务系统的场景了，实现这个就得用MySQL的隔离级别。

    2、四大特性（ACID）

  • 1、原子性：（Atomicity）：故名思议原子是最小的元素单位，所以一个事务是一个不可拆分的最小工作单元。整个事务操作要么全部执行成功，要么全部失败回滚。

    • 实现主要基于undo log日志实现的。
  • 2、一致性：（Consistency）：指数据库从一个一致性的状态转换到另外一个一致性的状态。要保证事务前后的状态要一致
  • 3、隔离性：（Isolation）：一个事务所做的修改在最终提交以前，对其他事务是不可见的。执行尽可能不受其他事务影响；InnoDB默认的隔离级别是可重复读（repeatable red,RR）。
    • RR的实现主要基于锁机制、数据的隐藏列、undo log和类next-key lock机制。

  • 4、持久性：（Durability）:一旦事务提交，则其所做的修改就会永久保存到磁盘上。是执行结果一直生效。

    • 实现主要基于redo log日志。

      2.1、原子性（Atomicity）

      2.1.1、定义

      事务的原子性就如原子操作一般，表示事务不可再分，其中的操作要么都做，要么都不做。

  • 如果事务中一个SQL语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态。只有0和1，没有其它值。

  • 事务的原子性表明事务就是一个整体，当事务无法成功执行的时候，需要将事务中已经执行过的语句全部回滚，使得数据库回归到最初未开始事务的状态。

  • 事务的原子性就是通过undo log日志进行实现的。当事务需要进行回滚时，InnoDB引擎就会调用undo log日志进行SQL语句的撤销，实现数据的回滚。

    2.1.2、undo log(回滚日志)

  • 1、undo log：实现原子性的关键，是当事务回滚时能够撤销所有已成成功执行的sql。

    • 当事务对数据库进行修改时，InnoDB会生成对应的undo log；如果事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子。
  • 2、undo log：属于逻辑日志，它记录的是sql执行相关的信息。当发生回滚时，InnoDB会根据undolog的内容做与之前相反的工作：
    • 对于每个insert，回滚时会执行delete；
    • 对于每个delete，回滚时会执行insert；
    • 对于每个update，回滚时会执行一个相反的update，把数据改回去。

以update操作为例：当事务执行update时，其生成的undo log中会包含被修改行的主键(以便知道修改了哪些行)、修改了哪些列、这些列在修改前后的值等信息，回滚时便可以使用这些信息将数据还原到update之前的状态。
MySQL事务 - 图1

2.2、持久性（Durability )

2.2.1、定义

事务的持久性是指当事务提交之后，数据库的改变就应该是永久性的，而不是暂时的。这也就是说，当事务提交之后，任何其它操作甚至是系统的宕机故障都不会对原来事务的执行结果产生影响。
事务的持久性是通过InnoDB存储引擎中的redo log日志来实现的

2.2.2、redo log(重做日志)

redo log存在的背景
InnoDB作为MySQL的存储引擎，数据是存放在磁盘中的，但如果每次读写数据都需要磁盘IO，效率会很低。为此，InnoDB提供了缓存(Buffer Pool)，Buffer Pool中包含了磁盘中部分数据页的映射，作为访问数据库的缓冲：

  • 当从数据库读取数据时，会首先从Buffer Pool中读取，如果Buffer Pool中没有，则从磁盘读取后放入Buffer Pool；当向数据库写入数据时，会首先写入Buffer Pool，Buffer Pool中修改的数据会定期刷新到磁盘中（这一过程称为刷脏）。

Buffer Pool的使用大大提高了读写数据的效率，但是也带了新的问题：如果MySQL宕机，而此时Buffer Pool中修改的数据还没有刷新到磁盘，就会导致数据的丢失，事务的持久性无法保证。
定义和作用
redo log：是InnoDB引擎层的日志，用来记录事务操作引起数据的变化，记录的是数据页的物理修改。
打个比方。数据库中数据的修改就好比你写的论文，万一哪天论文丢了怎么呢？以防这种不幸的发生，我们可以在写论文的时候，每一次修改都拿个小本本记录一下，记录什么时间对某一页进行了怎么样的修改。这就是重做日志。
redo log被引入来解决MySQL宕机

  • 1、当数据修改时，除了修改Buffer Pool中的数据，还会在redo log记录这次操作；
  • 2、当事务提交时，会调用fsync接口对redo log进行刷盘。如果MySQL宕机，重启时可以读取redo log中的数据，对数据库进行恢复。redo log采用的是WAL（Write-ahead logging，预写式日志），所有修改先写入日志，再更新到BufferPool，保证了数据不会因MySQL宕机而丢失，从而满足了持久性要求。
    • InnoDB引擎对数据的更新，是先将更新记录写入redo log日志，然后会在系统空闲的时候或者是按照设定的更新策略再将日志中的内容更新到磁盘之中。这就是所谓的预写式技术（Write Ahead logging）。这种技术可以大大减少IO操作的频率，提升数据刷新的效率。

既然redo log也需要在事务提交时将日志写入磁盘，为什么它比直接将Buffer Pool中修改的数据写入磁盘(即刷脏)要快呢？主要有以下两方面的原因：
1、刷脏是随机IO，因为每次修改的数据位置随机，但写redo log是追加操作，属于顺序IO。
2、刷脏是以数据页（Page）为单位的，MySQL默认页大小是16KB，一个Page上一个小修改都要整页写入；而redo log中只包含真正需要写入的部分，无效IO大大减少。

2.3、隔离性（Isolation）

2.3.1、定义

隔离性：研究的是不同事务之间的相互影响。即事务内部的操作与其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

  • 严格的隔离性，对应了事务隔离级别中的Serializable (可串行化)，但实际应用中出于性能方面的考虑很少会使用可串行化。

隔离性追求的是并发读写情形下事务之间互不干扰。简单起见，我们仅考虑最简单的读操作和写操作(暂时不考虑带锁读等特殊操作)，那么隔离性的探讨，主要可以分为两个方面：

  • 1、一个事务写操作对另一个事务写操作的影响：锁机制保证隔离性

  • 2、一个事务写操作对(另一个事务)读操作的影响：MVCC保证隔离性（面试大热点）

    2.3.2、锁机制

    隔离性：要求同一时刻只能有一个事务对数据进行写操作，InnoDB通过锁机制来保证这一点。
    锁机制的基本原理：

  • 1、事务在修改数据之前，需要先获得相应的锁；

  • 2、获得锁之后，事务便可以修改数据；
  • 3、该事务操作期间，这部分数据是锁定的，其他事务如果需要修改数据，需要等待当前事务提交或回滚后释放锁。

锁的分类：
锁机制并不是一个陌生的概念，在许多场景中都会利用到不同实现的锁对数据进行保护和同步。而在MySQL中，根据不同的划分标准，还可将锁分为不同的种类。

2.4、一致性（Consistency）

2.4.1、定义

一致性：数据库总是从一个一致性的状态转移到另一个一致性的状态。事务执行结束后，数据库的完整性约束没有被破坏，事务执行的前后都是合法的数据状态。

  • 数据库的完整性约束包括但不限于：实体完整性（如行的主键存在且唯一）、列完整性（如字段的类型、大小、长度要符合要求）、外键约束、用户自定义完整性（如转账前后，两个账户余额的和应该不变）。

下面举个例子:zhangsan 从银行卡转400到理财账户

2.4.2. 实现

一致性是事务追求的最终目标：前面提到的原子性、持久性和隔离性，都是为了保证数据库状态的一致性。此外，除了数据库层面的保障，一致性的实现也需要应用层面进行保障。
实现一致性的措施包括：

  • 保证原子性、持久性和隔离性，如果这些特性无法保证，事务的一致性也无法保证
  • 数据库本身提供保障，例如不允许向整形列插入字符串值、字符串长度不能超过列的限制等
  • 应用层面进行保障，例如如果转账操作只扣除转账者的余额，而没有增加接收者的余额，无论数据库实现的多么完美，也无法保证状态的一致