nolock的替代方案-提交读快照隔离[行版本控制]

with(nolock)并意味着没有锁，实际上在查询一张表时，还是有锁，会对对象增加架构锁，
防止表会修改，会对数据库增加共享锁。若使用drop index,则要等到架构锁释放。

sql server2005提供了快照隔离和读取已提交快照这两种新的不加锁、无阻塞的事务隔离级别，可使用
快照：每次从数据进行修改时，会在teampdb上存储上一版本
好处：
select不要求锁，会大大降低整个库的锁负载量
nolock会读取到未提交事务时修改的数据，而读快照读取的是修改之前的数据，故nolock易读取到脏数据
读快照与nolock相同的地方在于都不加共享锁，但都会加对象架构锁与数据库的共享锁，区别在于，nolock需要
在每个sql语句后加，而读快照不用，并用读快照不会读到未提交事务的数据。
行版本控制：在任何一个修改之前，先对修改前的版本做一个复制 ，后续的一切读操作都会去读这个复制的版本，修改将创建一个新的版本。在这种处理方式下，读、写操作不会相互阻塞。使用这种行版本控制机制的好处，是程序的并发性比较高，但是缺点是用户读到的虽然不是一个脏数据，但是可能是个正在被修改马上就要过期的数据值
【注：加上行版本控制后，会最大限度降低死锁，但不是没有死锁】

相关存储过程：select * from sys.dm_tran_version_store

把SQL Server数据库事务隔离级别设置为已提交读快照隔离：
如果直接运行下面的语句：
ALTER Database [mydbname] SET READ_COMMITTED_SNAPSHOT ON
会可能被阻塞很长时间。
你可以选择运行下面的语句：
if(charindex(‘Microsoft SQL Server 2005‘,@@version) > 0)
begin
declare @sql varchar(8000)
select @sql = ‘
ALTER DATABASE ‘ + DB_NAME() + ‘ SET SINGLE_USER WITH ROLLBACK IMMEDIATE ;
ALTER DATABASE ‘ + DB_NAME() + ‘ SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE ‘ + DB_NAME() + ‘ SET MULTI_USER;‘
Exec(@sql)
end
通过查询 sys.databases的 is_read_committed_snapshot_on字段
select is_read_committed_snapshot_on from sys.databases where name = DB_Name()
is_read_committed_snapshot_on如果为1表示目前为已提交读快照隔离级别

引用：
7 Things Developers Should Know About SQL Server
Using Read-Committed Snapshot Isolation - Mini-Lab
SQL Server已提交读快照隔离级别的设置
SQL Server 2005使用基于行版本控制的隔离级别初探