隔离级别决定事务间的可见程度，理解隔离级别是做什么的，你就能明白它们是如何阻止并发性副作用的。下面介绍各种事务隔离级别。
Serializable
Serializable隔离级别在SQL Server中是最悲观的隔离级别，它表明没有并发性问题。它简单地锁定一切，直到确保没有副作用发生，它通过范围锁实现这一点，这些锁要确保避免幻读的问题。范围锁如下图所示：
Repeatable Read
它没有serializable严格，不会出现范围锁。然而，这意味着把数据插入一个数据集中，会发生幻读的状况。Repeatbable Read会发生S锁，包括IS锁，直到事务结束。
Read Committed
Read Committed是SQL Server 2012默认的锁行为。在这样额环境中，S锁在特定的读取操作后释放，但是，在更悲观的隔离级别下，它们仍然被X锁阻塞。这种隔离级别能够显示一些并发问题，但是有更少的锁发生，这种行为在很多环境中常被认为是足够好的。在一个事务中读取一块数据，然后再读一次完全是可能的，因为另一个事务移动或改变了那块数据。Non-repeatable read因为是隐式的，不可能出现在Repeatable read隔离级别。下图显示了该隔离级别的锁的情况。
Read Uncommitted/NOLOCK
这里提到NOLOCK提示，因为它是很多开发者强制Read Uncommitted隔离级别。它是最小悲观的隔离级别，但仍然没归类到乐观。在Read Uncommitted隔离级别，S锁不会发生。如果事务正在使用不同的隔离级别，但使用NOLOCK提示时，会应用Read Uncommitted，其结果是脏读的问题。读取事务没有被X锁的数据阻塞，但是读取的数据可能是不可靠的值。性能得到提升，因为不需获取S锁，没有锁的兼容性要检查。在这个隔离级别下，一些锁仍能阻塞读----阻止任何东西获取临近的数据的锁，例如架构修改锁（Sch-M）
Snapshot
乐观的快照隔离级别通过命令SET TRANSACTION ISOLATION LEVEL SNAPSHOT打开，然而，必须如下配置数据库以允许它：
|
1
2
|
ALTER
DATABASE
AdventureWorks
SET
ALLOW_SNAPSHOT_ISOLATION
ON
;
|
Snapshot隔离级别设置后，事务开启时，数据库可以执行额外的工作，确保为了事务的时长，整个数据库呈现如同它开始的时候，对于读取，不需要锁。这或许听起来不错，但每次数据改变了，数据的前面的副本都必须被存储，直到每个活动的事务都完成（除了它自己的事务，其自然会用到更新的数据副本）。支持这种行为的数据存放在tempdb数据库。
Read Committed Snapshot
|
1
2
|
ALTER
DATABASE
AdventureWorks
SET
ALLOW_SNAPSHOT_ISOLATION
ON
;
|
Read Committed Snapshot类似快照隔离级别，但是它仅提供状态级别的读取一致性。因此，这种行为感觉更像读取提交隔离水平，有read committed一样的缺点，但没有read committed同样的阻塞问题。当另一个事务使用这种隔离级别请求锁定的数据是，行版本能够提供一个副本。然而，这些行的更老的版本在事务完成时被释放，从而允许比快照隔离级别更多的副作用。这种级别只能使用如下命令设置：
|
1
2
|
ALTER
DATABASE
AdventureWorks
SET
READ_COMMITTED_SNAPSHOT
ON
;
|
转载自：burgess_liu
本文转自UltraSQL51CTO博客，原文链接： http://blog.51cto.com/ultrasql/1839116，如需转载请自行联系原作者
