简单了解事务和日志和锁的关系

先来说说什么是事务，事务是数据库并发控制的基本单位，事务内有一系列的逻辑操作，需要一起成功或者一起失败，让数据库从一个一致性状态转换到另一个一致性状态，事务和日志和锁的关系在于事务的特性需要依靠这些机制来保证。

我们可以先看看事务的四大特性：

• 原子性（使用undo log）：一个事务中的所有操作都是不可分割的，要么全部完成，要么全部失败

• 隔离性（锁 or MVCC）：防止多个事务间并行操作时，其它事务对本事务操作数据的影响

• 持久性（使用redo log）：事务提交后，数据被保存在磁盘中，数据不会丢失

• 一致性（所追求）：结果符合约束，比如有钱才能转账、转账双方加起来银行账户的钱总和总是不变

先来说说原子性，我们知道活跃的事务一般有两种结果，失败回滚或者成功提交，对于失败回滚，我们会用到undo log，对于事务内的每次逻辑操作（也就是一条SQL语句），会把未修改前的快照行数据保存到undo log页，这也就形成了undo log版本链（本质上是每个行记录的隐藏字段roll_pointer指针指向了undo log页内的先前的快照行记录）。

当发生错误需要事务回滚的时候，我们根据undo log页保存的旧数据来进行事务的回滚，保证了事物的原子性，如何保证回滚哪些记录呢，这就还要依靠行记录的另一个隐藏字段trx_id也即是事务id，只回滚undo log版本链中的本事务id的行记录。

再来谈谈持久性吧，在原子性那里说过事务可能会失败回滚，这里我们来谈谈成功提交的情况，当事务成功提交，我们需要把这些更改的行记录都保存到redo log，避免丢失.

当然在事务的途中，对行记录的修改也会被记录到redo log，redo log会根据设定的持久化策略进行刷盘，这里使用redo log有两个原因，写redo log的速度更快（因为数据量更小，只需要记录哪一页的哪个偏移量位置发生了什么变动，无需记录整条行记录），并且redo log刷盘是顺序I/O循环写，效率更高，后期再慢慢把脏的数据页刷盘就好了。

当数据库宕机后，由于redo log刷盘了，对于已经提交的事务，可以根据redo log进行数据的恢复，对于未提交的事务，可以根据redo log配合undo log（undo log也会被redo log记录进行持久化）进行数据的恢复（本质上还是利用了undo log进行数据恢复），保证了事务的持久性。

最后来看看隔离性，主要是为了处理事务的并发问题，对于数据我们一般有读、写两种操作：

对于写操作我们一般就是上锁（索引悲观锁或者版本号乐观锁）

那么对于读操作（一种是快照读，一种是当前读）有两种解决方案，一种是上锁（对于当前读，会上独占锁，如select ... for update），另一种是依靠MVCC（读已提交和可重复读的快照读，如普通select依靠这个实现），每个事务只能读到行记录的undo log版本链它有权限的部分，对于当前读可以读到所有的版本，对于快照读可以看到的版本如下：

1. 事务已提交的版本（creator_trx_id < min_trx_id），可见

2. 事务未开始的版本（creator_trx_id > max_trx_id），不可见

3. 事务活跃的版本（creator_trx_id 属于 m_ids），不可见

注意到读已提交和可重复读的视图Read View产生的时机不同，Read View其实就是保存着事务ID的一个集合，读已提交每个SQL都会产生新的Read View（因为默认每个SQL都会开启一个新的事务），可重复读的Read View只会在事务开始产生，事务期间都是同一个Read View，这也是可重复读隔离级别可重复读的原因。

接下来简单谈一谈什么是MVCC吧，MVCC又称多版本并发控制，主要是利用读已提交和可重复读隔离级别下事务启动产生的Read View内的本事务id以及当前活跃的事务id集合配合undo log版本链来判断查询语句想查询的行记录本事务可见的版本。