前言
上一篇SQL Server详细讲解了隔离级别，但是对基于行版本中的SNAPSHOT隔离级别仍未完全理解，本节再详细讲解下，若有疑义或不同见解请在评论中提出，一起探讨。
SNAPSHOT行版本隔离级别
在SNAPSHOT隔离级别下，读取者在读取数据时， 它是确保获得事务启动时最近提交的可用行版本，这意味着，保证获得的是提交后的读取并且可重复读取，以及确保获得不是幻读，类似于SERIALIZABLE级别中一样，但是此隔离级别依赖于行版本，而不是使用共享锁，要想在企业部署的SQL Server实例中允许事务以SNAPSHOT隔离级别工作，首先需要在查询窗口执行以下代码打开快照隔离级别。如下：
ALTER DATABASE TSQL2012 SET ALLOW_SNAPSHOT_ISOLATION ON
下面我们再用一个简单的例子来详细讲解其过程。首先我们启用上述SNAPSHOT隔离级别，然后查询某个表的修改日期列，如下：
ALTER DATABASE AdventureWorks2012 SET ALLOW_SNAPSHOT_ISOLATION ON
GO
SELECT
ModifiedDate
FROM HumanResources.Shift
GO
如上是我们正常查询出的修改日期列（ModifiedDate）。接下来我们创建两个会话，一个是写入会话（会话一），另外一个是查询会话（会话二）来证明SNAPSHOT隔离级别的作用。
SET TRANSACTION ISOLATION LEVEL SNAPSHOT BEGIN TRAN UPDATE HumanResources.Shift SET ModifiedDate = GETDATE() GO
我们设置写入者的隔离级别为SNAPSHOT，然后更新其修改日期为当前日期，但是我们此时只是开启了事务并未提交该写入事务。与此同时我们再来创建一个查询会话（会话二）来查询修改日期列，如下查询会话也未提交事务。
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
BEGIN TRAN
SELECT
ModifiedDate
FROM HumanResources.[Shift]
此时我们看到查询出的修改日期依然是原始值并未进行修改，此时我们再来提交写入者事务（会话一），在上述写入者事务后面添加如下一句。
COMMIT TRAN
此时再来在会话二中查询修改日期，结果依然是原始值，如下：
此时我们再来提交查询事务（会话二），再来查询，结果如下
在上一篇仅仅只讲述了最后结果的变化，并未叙述其中过程到底是怎样的，请往下看。
SNAPSHOT基于行版本隔离级别过程叙述
（1）会话一中开启事务并更新修改日期列，但是并未提交会话一中的事务，换句话说，原始值将依然有效，所以SNAPSHOT（快照隔离级别）导致仍然可以读取到原始值。
（2）会话二中开启事务并读取原始值，在这个阶段中，数据库引擎将创建一个读取的行副本到tempdb临时数据库中，所以在会话二中的所有读取事务都将从tempdb临时数据库中读取。
（3）会话一提交了事务并将其修改的值储存到了表中，注意，此时改变的值只是响应到了表中，而会话二中在tempdb临时数据库中副本依然保持不变。
（4）会话二再次读取行时，此时将从tempdb临时数据库中去读取且读取到的依然是原始值，因为在会话二中还并未提交事务。
（5）会话二提交了事务，此时将销毁在tempdb临时数据库中的副本，在此之后将无法再读取原始值。
（6）会话二再次读取行时，因为在提交事务之后在tempdb临时数据库中没有行，所以现在将去表中获取新行。
若我们在上述会话二中查询并未开启事务，这就意味着所有读取将直接从表中读取，同时将不会创建副本到tempdb临时数据库中，进一步讲，此时将导致查询阻塞，所以从这里我们知道开启基于行版本的SNAPSHOT隔离级别将有利于减少死锁情况的发生，提高并发性能。
总结
本节我们再次很详细讲解了基于行版本的SNAPSHOT隔离级别的过程描述，总算是明白了基于行版本隔离级别的原理。