这里的视图可以理解为数据副本，每次创建视图时，将当前已持久化的数据创建副本，后续直接从副本读取，从而达到数据隔离效果。
隔离级别的实现我们每一次的修改操作，并不是直接对行数据进行操作。
比如我们设置 id 为 3 的行的 A 属性为 10，并不是直接修改表中的数据，而是新加一行。
同时数据表其实还有一些隐藏的属性，比如每一行的事务 id，所以每一行数据可能会有多个版本，每一个修改过它的事务都会有一行，并且还会有关联的 undo 日志，表示这个操作原来的数据是什么，可以用它做回滚。
那么为什么要这么做？
因为如果我们直接把数据修改了，那么其他事务就用不了原先的值了，违反了事务的一致性。
那么一个事务读取某一行的数据到底返回什么结果呢？
取决于隔离级别，如果是 Read Committed，那么返回的是最新的事务的提交值，所以未提交的事务修改的值是不会读到的，这就是 Read Committed 实现的原理。
如果是 Read Repeatable 级别，那么只能返回发起时间比当前事务早的事务的提交值，和比当前事务晚的删除事务删除的值。这其实就是 MVCC 方式。
undo logundo log 中存储的是老版本数据。假设修改表中 id=2 的行数据，把 修改为 Name = 'B2' ，那么 undo 日志就会用来存放 的记录，如果这个修改出现异常，可以使用 undo 日志来实现回滚操作，保证事务的一致性。
当一个旧的事务需要读取数据时，为了能读取到老版本的数据，需要顺着 undo 链找到满足其可见性的记录。当版本链很长时，通常可以认为这是个比较耗时的操作。
假设一个值从 1 被按顺序改成了 2、3、4，在回滚日志里面就会有类似下面的记录。
当前值是 4，但是在查询这条记录的时候，不同时刻启动的事务会有不同的 read-view。
如图中看到的，在视图 A、B、C 里面，这一个记录的值分别是 1、2、4，同一条记录在系统中可以存在多个版本，就是数据库的多版本并发控制（MVCC）。对于 read-view A，要得到 1，就必须将当前值依次执行图中所有的回滚操作得到。
同时你会发现，即使现在有另外一个事务正在将 4 改成 5，这个事务跟 read-view A、B、C 对应的事务是不会冲突的。
另外，在回滚段中的 undo log 分为: insert undo log 和 update undo log：
insert undo log : 事务对 insert 新记录时产生的 undolog，只在事务回滚时需要，并且在事务提交后就可以立即丢弃。（谁会对刚插入的数据有可见性需求呢！！）
update undo log : 事务对记录进行 delete 和 update 操作时产生的 undo log。不仅在事务回滚时需要，一致性读也需要，所以不能随便删除，只有当数据库所使用的快照中不涉及该日志记录，对应的回滚日志才会被 purge 线程删除。
何时删除？
在不需要的时候才删除。也就是说，系统会判断，当没有事务再需要用到这些回滚日志时，回滚日志会被删除。
就是当系统里没有比这个回滚日志更早的 read-view 的时候。
长事务直观感觉，一个事务花费很长时间不能够结束，就是一个长的事务，简称长事务（Long Transaction）。
长事务是数据库用户经常会碰到且是非常令人头疼的问题。长事务处理需要恰当进行，如处理不当可能引起数据库的崩溃，为用户带来不必要的损失。
根据上面的论述，长事务意味着系统里面会存在很老的事务视图。
由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的 undo log 都必须保留，这就会导致大量占用存储空间。
在 MySQL 5.5 及以前的版本，回滚日志是跟数据字典一起放在 ibdata 文件里的，即使长事务最终提交，回滚段被清理，文件也不会变小。
除了对回滚段的影响，长事务还占用锁资源，也可能拖垮整个库，这个我们会在后面讲锁的时候展开。
因此，我们要尽量避免长事务。
小结这一节主要是事务的隔离级别，主要需要记住几个隔离级别、了解一下实现方式。
感觉东西有点乱，涉及了 MVCC 的东西，作者也没有展开，我能力有限，也就没有再深挖。后续，作者在涉及相关知识点时，我们再进行探讨。