* 在以前老版本，只支持1个 rollback segment，只能记录 1024 个 undo log segment

* 与原子性、持久性侧重于研究事务本身不同，隔离性研究的是不同事务之间的相互影响

| repeatable read | 可重复读 | 幻读 | MySQL（避免幻读） |

* 丢失更新 (Lost Update)：当两个或多个事务选择同一行，最初的事务修改的值，被后面事务修改的值覆盖，所有的隔离级别都可以避免丢失更新

> 可重复读的意思是不管读几次，结果都一样，可以重复的读

每次对数据库记录进行改动，都会将旧值放到一条undo日志中，算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被 roll_pointer 属性连接成一个链表，把这个链表称之为**版本链**，版本链的头节点就是当前记录最新的值，链尾就是最早的旧记录

* 事务1修改该行数据时，数据库会先对该行加排他锁，然后先把该行数据拷贝到 undo log 中作为旧记录，拷贝完毕后修改该行 name 为Tom，并且修改隐藏字段的事务ID为当前事务1的ID（默认为 1 之后递增），回滚指针指向拷贝到 undo log 的副本记录，事务提交后，释放锁

为了实现 InnoDB 的 MVCC 机制，更新或者删除操作都只是设置一下老记录的 deleted_bit，并不真正将过时的记录删除，为了节省磁盘空间，InnoDB 有专门的 purge 线程来清理 deleted_bit 为true的记录，purge 线程维护了一个 Read view（这个 Read view 相当于系统中最老活跃事务的 Read view），如果某个记录的 deleted_bit 为true，并且 DB_TRX_ID 相对于 purge 线程的 Read view 可见，那么这条记录一定是可以被安全清除的

Read View 是事务进行快照读操作时产生的读视图，该事务执行快照读的那一刻会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID，用来做可见性判断，根据视图判断当前事务能够看到哪个版本的数据

工作流程：将版本链的头节点的事务ID（最新数据事务ID）DB_TRX_ID 取出来，与系统当前活跃事务的 ID 对比，如果 DB_TRX_ID 不符合可见性，那就通过 DB_ROLL_PTR 回滚指针去取出 undo log 中的下一个 DB_TRX_ID 再比较，直到找到满足特定条件的 DB_TRX_ID，该事务 ID 所在的旧记录就是当前事务能看见的最新的记录

- low_limit_id：生成 Read View 时系统应该分配给下一个事务的 id 值，m_ids 中的最大值加1

- creator_trx_id：生成该 Read View 的事务的事务id，就是判断该id的事务能读到什么数据

creator 创建一个 Read View，进行可见性算法分析：（**解决了读未提交**）

* db_trx_id < up_limit_id：该版本对应的事务 ID 小于 Read view 中的最小活跃事务ID，则这个事务在当前事务之前就已经被 COMMIT 了，对 creator 可见

* db_trx_id >= low_limit_id：该版本对应的事务 ID 大于 Read view 中当前系统的最大事务ID，则说明该数据是在当前 Read view 创建之后才产生的，对 creator 不可见

* 在列表中，说明该版本对应的事务正在运行，数据不能显示（不能读到未提交的数据）

- 当前读：通过 next-key 锁（行锁+间隙锁）来解决问题

对于 UPDATE、DELETE 和 INSERT 语句，InnoDB 会自动给涉及数据集加排他锁；对于普通 SELECT 语句，InnoDB 不会加任何锁

加锁的基本单位是 next-key lock，该锁是行锁和这条记录前面的 gap lock 的组合，就是行锁加间隙锁。