事务是由存储引擎实现的，来看一下innodb 的事务实现
总结来说，事务的隔离性由多版本控制机制和锁实现，而原子性、一致性和持久性通过InnoDB的redo log、undo log和Force Log at Commit机制来实现。

1.四大特性

Atomicity（原子性）：构成事务的的所有操作必须是一个逻辑单元，要么全部执行，要么全部不执行。
Consistency（一致性）：数据库在事务执行前后状态都必须是稳定的或者是一致的。
Isolation（隔离性）：事务之间不会相互影响。
由锁机制和MVCC机制来实现的
MVCC(多版本并发控制)：优化读写性能（读不加锁、读写不冲突）
Durability（持久性）：事务执行成功后必须全部写入磁盘。

2. 开启和关闭事务

BEGIN 或 START TRANSACTION；显式地开启一个事务；
COMMIT 也可以使用 COMMIT WORK 提交事务
ROLLBACK 有可以使用 ROLLBACK WORK 回滚事务，

3. 原子性，持久性和一致性

原子性，持久性和一致性主要是通过redo log、undo log和Force Log at Commit机制机制来完成
的。redo log用于在崩溃时恢复数据，undo log用于对事务的影响进行撤销，也可以用于多版本控制。而Force Log at Commit机制保证事务提交后redo log日志都已经持久化。

4. RedoLog

落盘机制
redo log写入磁盘时，必须进行一次操作系统的fsync操作，防止redo log只是写入了操作系统的磁盘缓存中。参数innodb_flush_log_at_trx_commit可以控制redo log日志刷新到磁盘的策略

image.png

5. UndoLog

数据库崩溃重启后需要从redo log中把未落盘的脏页数据恢复出来，重新写入磁盘，保证用户的数据不丢失。当然，在崩溃恢复中还需要回滚没有提交的事务。由于回滚操作需要undo日志的支持，undo日志的完整性和可靠性需要redo日志来保证，所以崩溃恢复先做redo恢复数据，然后做undo回滚。

在事务执行的过程中，除了记录redo log，还会记录一定量的undo log。undo log记录了数据在每个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log进行回滚操作。

image.png

数据和回滚日志的逻辑存储结构

image.png

undo log的存储不同于redo log，它存放在数据库内部的一个特殊的段(segment)中，这个段称为回滚段。回滚段位于共享表空间中。
undo段中的以undo page为更小的组织单位。undo page和存储数据库数据和索引的页类似。因为redo log是物理日志，记录的是数据库页的物理修改操作。所以undolog（也看成数据库数据）的写入也会产生redo log，也就是undo log的产生会伴随着redo log的产生，这是因为undo log也需要持久性的保护。如上图所示，表空间中有回滚段和叶节点段和非叶节点段，而三者都有对应的页结构。

数据库执行的流程

image.png

事务进行过程中，每次sql语句执行，都会记录undo log和redo log，然后更新数据形成脏页，然后redo log按照时间或者空间等条件进行落盘，undo log和脏页按照checkpoint进行落盘，落盘后相应的redo log就可以删除了。

此时，事务还未COMMIT，如果发生崩溃，则首先检查checkpoint记录，使用相应的redo log进行数据和undo log的恢复，然后查看undo log的状态发现事务尚未提交，然后就使用undo log进行事务回滚。事务执行COMMIT操作时，会将本事务相关的所有redo log都进行落盘，只有所有redo log落盘成功，才算COMMIT成功。然后内存中的数据脏页继续按照checkpoint进行落盘。如果此时发生了崩溃，则只使用redo log恢复数据。

image.png

6. 隔离性

事务的并发问题

丢失更新：两个事务针对同一数据都发生修改操作时，会存在丢失更新问题。
脏读：一个事务读取到另一个事务未提交的数据。
不可重复读：一个事务因读取到另一个事务已提交的update或者delete数据。导致对同一条记录读取两次以上的结果不一致。
幻读：一个事务因读取到另一个事务已提交的insert数据。导致对同一张表读取两次以上的结果不一致。

事务的隔离级别
四种隔离级别（SQL92标准）：
现在来看看MySQL数据库为我们提供的四种隔离级别（由低到高）：

Read uncommitted (读未提交)：最低级别，任何情况都无法保证。
Read committed (RC，读已提交)：可避免脏读的发生。
Repeatable read (RR，可重复读)：可避免脏读、不可重复读的发生。
（注意事项：InnoDB的RR还可以解决幻读，主要原因是Next-Key（Gap）锁，只有RR才能使用 Next-Key锁）
Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。
（由MVCC降级为Locking-Base CC）
MVCC 多版本并发控制 LBCC 锁控制

MVCC使得数据库读不会对数据加锁，普通的SELECT请求不会加锁，提高了数据库的并发处理能力。借助MVCC，数据库可以实现READ COMMITTED，REPEATABLE READ等隔离级别，用户可以查看当前数据的前一个或者前几个历史版本，保证了ACID中的I特性（隔离性)。

使用锁机制(LBCC)可以解决上述的问题。查询总额事务会对读取的行加锁，等到操作结束后再释放所有行上的锁。

7. InnoDB的MVCC实现

在MVCC并发控制中，读操作可以分成两类：快照读 (snapshot read)与当前读 (current read)。

• 快照读，读取的是记录的可见版本 (有可能是历史版本)，不用加锁。(select)
• 当前读，读取的是记录的最新版本，并且当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这 条记录。

在一个支持MVCC并发控制的系统中，哪些读操作是快照读？哪些操作又是当前读呢？

以MySQL InnoDB为例：

• 快照读：简单的select操作，属于快照读，不加锁。(当然，也有例外，下面会分析) 不加读锁 读历史版本

• 当前读：特殊的读操作，插入/更新/删除操作，属于当前读，需要加锁。 加行写锁 读当前版本一致性非锁定读

一致性非锁定读(consistent nonlocking read)是指InnoDB存储引擎通过多版本控制(MVCC)读取当前数据库中行数据的方式。

如果读取的行正在执行DELETE或UPDATE操作，这时读取操作不会因此去等待行上锁的释放。相反地，InnoDB会去读取行的一个最新可见快照。

Undolog

1、回滚
2、让mvcc读历史版本

image.png

InnoDB行记录有三个隐藏字段：分别对应该行的rowid、事务号db_trx_id和回滚指针db_roll_ptr，其中db_trx_id表示最近修改的事务的id，db_roll_ptr指向回滚段中的undo log。

根据行为的不同，undo log分为两种：insert undo log和update undo log

insert undo log：
是在 insert 操作中产生的 undo log。因为 insert 操作的记录只对事务本身可见，rollback 在该事务中直接删除 ，不需要进行 purge 操作 (purge Thread)

update undo log ：
是 update 或 delete 操作中产生的 undo log，因为会对已经存在的记录产生影响，rollback MVCC机制会找他的历史版本进行恢复是 update 或 delete 操作中产生的 undo log，因为会对已经存在的记录产生影响，为了提供 MVCC机制，因此 update undo log 不能在事务提交时就进行删除，而是将事务提交时放到入 history list 上，等待 purge 线程进行最后的删除操作。

image.png

事务链表

MySQL中的事务在开始到提交这段过程中，都会被保存到一个叫trx_sys的事务链表中，这是一个基本的链表结构：
ct-trx --> trx11 --> trx9 --> trx6 --> trx5 --> trx3;
事务链表中保存的都是还未提交的事务，事务一旦被提交，则会被从事务链表中摘除。
RR隔离级别下，在每个事务开始的时候，会将当前系统中的所有的活跃事务拷贝到一个列表中(read view)
RC隔离级别下，在每个语句开始的时候，会将当前系统中的所有的活跃事务拷贝到一个列表中(read view)
show engine innodb status ,就能够看到事务列表。

ReadView

当前事务（读）能读哪个历史版本？
Read View是事务开启时当前所有事务的一个集合，这个类中存储了当前Read View中最大事务ID及最小事务ID。
这就是当前活跃的事务列表。如下所示，
ct-trx --> trx11 --> trx9 --> trx6 --> trx5 --> trx3;
ct-trx 表示当前事务的id，对应上面的read_view数据结构如下，

read_view->creator_trx_id = ct-trx; 
read_view->up_limit_id = trx3; 低水位 
read_view->low_limit_id = trx11; 高水位 
read_view->trx_ids = [trx11, trx9, trx6, trx5, trx3];

low_limit_id是“高水位”，即当时活跃事务的最大id，如果读到row的db_trx_id>=low_limit_id，说明这些id在此之前的数据都没有提交，如注释中的描述，这些数据都不可见。

if (trx_id >= view->low_limit_id) { 
return(FALSE); 
}
注：readview 部分源码

up_limit_id是“低水位”，即当时活跃事务列表的最小事务id，如果row的db_trx_id<up_limit_id,说明这些数据在事务创建的id时都已经提交，如注释中的描述，这些数据均可见。

if (trx_id < view->up_limit_id) { 
return(TRUE); 
}

row的db_trx_id在low_limit_id和up_limit_id之间，则查找该记录的db_trx_id是否在自己事务的
read_view->trx_ids列表中，如果在则该记录的当前版本不可见，否则该记录的当前版本可见。

不同隔离级别ReadView实现方式

1. read-commited:

在每次语句执行的过程中，都关闭read_view, 重新在row_search_for_mysql函数中创建当前的一份read_view。这样就会产生不可重复读现象发生。

2. repeatable read：

在repeatable read的隔离级别下，创建事务trx结构的时候，就生成了当前的global read view。使用trx_assign_read_view函数创建，一直维持到事务结束。在事务结束这段时间内 每一次查询都不会重新重建Read View ， 从而实现了可重复读。