表1.SQL Server中锁的粒度
锁的升级
前面说到锁的粒度和性能的关系。实际上，每个锁会占96字节的内存，如果有大量的小粒度锁，则会占据大量的内存。
下面我们来看一个例子，当我们选择几百行数据时(总共3W行),SQL Server会加对应行数的Key锁，如图9所示
图9.341行，则需要动用341个key锁
但当所取得的行的数目增大时，比如说6000（表中总共30000多条数据）,此时如果用6000个键锁的话，则会占用大约96*6000=600K左右的内存，所以为了平衡性能与并发之间的关系，SQL Server使用一个表锁来替代6000个key锁，这就是所谓的锁升级。如图10所示。
图10.使用一个表锁代替6000个键锁
虽然使用一个表锁代替了6000个键锁，但是会影响到并发，我们对不在上述查询中行做更新(id是50001，不在图10中查询的范围之内)，发现会造成阻塞，如图11所示。
图11.锁升级提升性能以减少并发为代价
锁模式当SQL Server请求一个锁时，会选择一个影响锁的模式。锁的模式决定了锁对其他任何锁的兼容级别。如果一个查询发现请求资源上的锁和自己申请的锁兼容，那么查询就可以执行下去，但如果不兼容，查询会被阻塞。直到所请求的资源上的锁被释放。从大类来看，SQL Server中的锁可以分为如下几类:
共享锁(S锁）:用于读取资源所加的锁。拥有共享锁的资源不能被修改。共享锁默认情况下是读取了资源马上被释放。比如我读100条数据，可以想像成读完了第一条，马上释放第一条，然后再给第二条数据上锁，再释放第二条，再给第三条上锁。以此类推直到第100条。这也是为什么我在图9和图10中的查询需要将隔离等级设置为可重复读，只有设置了可重复读以上级别的隔离等级或是使用提示时，S锁才能持续到事务结束。实际上，在同一个资源上可以加无数把S锁。
排他锁(X锁): 和其它任何锁都不兼容，包括其它排他锁。排它锁用于数据修改，当资源上加了排他锁时，其他请求读取或修改这个资源的事务都会被阻塞，知道排他锁被释放为止。
更新锁(U锁) :U锁可以看作是S锁和X锁的结合，用于更新数据，更新数据时首先需要找到被更新的数据，此时可以理解为被查找的数据上了S锁。当找到需要修改的数据时，需要对被修改的资源上X锁。SQL Server通过U锁来避免死锁问题。因为S锁和S锁是兼容的，通过U锁和S锁兼容，来使得更新查找时并不影响数据查找，而U锁和U锁之间并不兼容，从而减少了死锁可能性。这个概念如图12所示。
