阻塞与死锁 之五 分析

总结以上分析，如果数据库应用开发者或管理员想要影响SQLServer锁的申请和释放行为，以缓解阻塞或死锁问题，需要考虑的因素有：

1.   事务隔离级别的选定。

事务隔离级别越高，隔离度就越高，并发度也就越差。如果选择了比较高的隔离级别，SQLServer不可避免地要申请更多的锁，持有的时间也会增加。所以在设计应用的时候，一定要和用户谈好，尽量选择默认的隔离级别（READCOMMITTED）。

2.   事务的长短和事务的复杂度。

事务的长短和复杂度决定了这个事务在SQLServer内部会持续多长时间，也能决定SQL Server会同时在多少张表和索引上申请和持有锁。事务越简单，就越不容易发生阻塞或死锁。所以这也必须和用户商量好，尽量避免在一个事务里做很多事情。

3.   从应用整体并发度考虑，单个事务一次处理的数据量不能过多。

应用的性能，不单要衡量单个连接的处理速度，也要衡量在并发处理的情况下，整体的平均速度怎么样。从连接个体来讲，可能在一个事务里把数据一次都处理掉比较快。但是如果处理的数据量很大，就会影响到其他连接同时访问同一对象。所以如果一个应用的并发要求比较高，就一定要严格控制单个事务处理的数据量。如果有什么事务操作需要访问或修改表格内的大量数据，最好调整到并发用户比较少的时候运行。

4.   针对语句在表格上设计合适的索引。

合适的索引能使SQL Server在读取尽可能少的数据量的前提下，把需要处理的数据找到。如果没有合适的索引，SQL Server在做SELECT、UPDATE和DELETE的时候，会申请比要处理的目标数据量多得多的锁（参见14.5节的讨论），从而导致阻塞或者死锁。这种情形可以通过加索引的方式提高并发度。同时，SQL Server在做UPDATE、INSERT和DELETE的时候，会对有关联的所有索引都做修改，在它们上面申请锁。所以从这个角度讲，索引越多，产生的锁的数目也就越多，阻塞和死锁的几率也就会越高。

所以数据库设计员需要做的，是要确保有足够的索引，防止语句做全表扫描，但是也要去掉那些对语句运行贡献不大的索引。不能随便往表格上加索引。