我估计被吸引到这个文字中的是 6种, 大部分人是想进来看看不是4种吗？
实际上之前的一段时间，我的认知也是4种隔离级别，这是通过我们的ANSI SQL 表中中定义的 isolation level。
在ANSI/ISO SQL -92 定义了四种隔离级别， RU , RC , RR, Serializable, 这四种，当然常用的RC,RR，解决了脏读和幻读的问题。ISOLATION的定义一直与数据库系统的性能有关，隔离的级别越低，那么性能就会越好。
而后随着研究的进步，隔离级别进行了分化，延展出另外两种隔离级别
其中一种就是今天要说的 Snapshot lsolation
今天主要来去重新理解一直在用但其实个人概念并不清楚的 snapshot isolation. 根据官方的文档中提出，snapshot isolation
大致的意思是，当事务读取数据的时候，此时数据的状态是commit的状态，而在读取的时间被命名为 start-timestamp, 在这期间不管是这批数据正在被别的事务处理或者操作， 读取数据的事务的第一次对数据的读取都是不被限制的，在这个snapshot lsolation 中是不会阻止任何对数据的读取的行为。而当其他事务修改了这批数据，则会影响SNAPSHOT LEVEL的中事务对数据的第二次读取，同时对于还未读取这批数据的其他事务来说，刚才我们的start-timestarmp 将失效与还未读取数据的事务。
与RU,RC RR, S ，四种隔离级别强调锁的概念， SNAPSHOT Isolation 强调的是时间对事务的影响。（个人理解）
我们下面画一个图来说明此问题。
以上都是在比较单纯的情况下的非复杂的对SNAPSHOT 的描述
1 事务1 读取了数据集合A （实际上集合A 可能是N 行数据）
2 在读取数据集合A 时， 事务1 会获取一个start_time 来标注操作事务的开始时间。也就是针对这个事务生成SNAPSHOT 的时间。
3 在经过一段时间后，事务1 要进行commit 此时获得commit时间戳 commit-timestamp ， 在提交事务前并未有其他事务对A 数据集合有操作，
则提交顺利完成。
上面的这个图形的问题在没有并发，并且没有多个事务来修改同一个数据集合，那么实际上SNAPSHOT LEVEL 要面临非常复杂的问题，就是 并发和数据的修改同时发生。
那么这里我们需要将问题分析，到底哪些是 SNAPSHOT LEVEL 应该负责的地方。
1 每个事务读取数据的snapshot，snapshot 产生于对这组数据库的copy
2 所有的写操作会被收集到事务的写集合中
3 在提交的时间，所有事务的提交的都会被比较，如果这些提交的信息都是无关联的，则可以直接进行commit;
如果这些信息是有关联的，则根据时间戳的比较来进行数据的commit 通常，commit 时间戳获取早的事务，可以进行commit
实际上SNAPSHOT 要解决的问题，
1 读操作时不会陷入block 和死锁的问题中，SNAPSHOT 本身提高了数据库系统的事务处理的性能。
2 避免了 脏读，非一致性读，以及丢失更新，和不可重复读等多个问题
以上是PG 对于SNAPSHOT 部分的代码。
以上是MYSQL INNODB 操作引起对于SNAPSHOT 的部分代码
那么这里 POSTGRESQL 和MYSQL 在实现SNAPSHOT 功能中，老的数据版本分表存在表本体和UNDO LOG中， 同时对于SNAPSHOT 的力度都是针对 tuple 和 row, 而时间戳都包含在各自的事务记录中。
总结：
SNAPSHOT LEVEL 解决了锁解决了的事务隔离级别和性能之间的矛盾问题，有效的提高了数据库并发的性能问题。
但在分布式数据库系统中，SNAPSHOT 又有了新的挑战，时间（timestamp）还是解决问题的核心。
