6种 数据库隔离级别中的SNAPSHOT隔离级别

我估计被吸引到这个文字中的是 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）还是解决问题的核心。