3、从应用整体并发度考虑，但是事务一次处理的数据量不能过多：如果一个应用的并发要求比较高，一定要严格控制单个事务处理的数据量。如果有什么事务操作需要访问或修改表内大量数据，好调整到并发用户比较少的时候运行。

　　4、针对语句在表格上设计合适的索引：如果没有合适的索引，在做SELECT /UPDATE/DELETE 的时候，申请多得多的锁。对这种情况，可以通过加索引提高并发性。但是，索引越多，申请的锁数目也会越多。对于设计人员，要确保有足够的索引，防止语句做全表扫描。但也要去掉对语句运行贡献不大的索引，不能随便往表格上加索引。

　　数据库引擎中基于行版本控制的隔离级别：

　　在默认设置下，一个读操作会和一个写操作相互阻塞。在未提交读，虽然不会，但是读操作可能读到脏数据。大部分用户是不能接受的。

　　从2005以后，引入了行版本控制机制。好处是程序并发性比较高但是用户读取数据时虽然不是脏数据但是可能是一个正在被修改马上要过期的数据值，容易产生逻辑错误。

　　SQLServer 有两种行版本控制：

　　使用行版本的已提交隔离（READ_COMMITTED_SNAPSHOT）和直接使用SNAPSHOT事务隔离级别。

　　● READ_COMMITTED_SNAPSHOT数据库选项为ON时，READ_COMMITTED事务通过使用行版本控制提供语句级读取一致性。

　　● ALLOW_SNAPSHOT_ISOLATION数据库选项为ON时，SNAPSHOT事务通过使用行版本控制提供事务级读取一致性。

　　可以使用ALTER DATABASE XXX SET READ_COMMITTED_SNAPSHOT/ ON；来开启。

　　注意：行版本控制并不是消除阻塞和死锁的万灵药。必须考虑两个问题：

　　1、终用户是否接受行版本控制下的运行结果？

　　2、SQL Server 是否能支持行版本控制带来的额外负荷？因为行版本放在tempdb，对SQL Server会造成额外的负载。