在谈谈SQLServer的锁机制之前，来思考以下这个场景：当你在酷暑的时候骑着自己的小车往目的地行走时，路上连续遇到几个时间很长的红灯，是不是很郁闷？有时候你可能实在受不了闯了个红灯，其实在大部分情况下问题不大，如果通行的汽车很多那就不好说了。因为不遵守规则的人太多，都为了达到目的去走捷径，不愿意等待。这样才有了交警。交警的作用就是维护这些红绿灯的规则。这些红绿灯就像锁一样，锁住或延长你去目的地的时间。但是如果没有交警大家又不自由遵守红绿灯规则会导致什么呢？大家想想都知道。

　　这个系列的一篇文章中提供的事务管理器中有个锁管理器就是这里的交警。它维护着SQLServer中的锁。前段提到的大部分情况指的就是在系统事务量不大的时候，这时候的锁永远不会是什么大问题。除非你知道你的系统永远就给几个人用，否则考虑到系统以后的并发量上升不出现数据与效率问题，那你得深入了解锁机制。在研究锁之前，假定你已经了解事务的ACID概念，它是整个SQLServer的精髓所在。如果没有事务那就不用谈锁了，除了事务需要锁以外其他任何东西都需要这个让SQL不自由的机制。说到底锁是一个平衡并发与数据安全的机制，如果没有锁，任何SQL都能覆盖其他SQL执行的数据，那么数据会出现不一致的情况。如果锁得太狠，那将影响数据库系统的并发性以及效率（包括锁本身带来的额外开销）。这时候就需要去权衡，SQLServer锁管理器就充当权衡这两者关系的角色，如下图所示：

　　SQLServer中锁的知识点实在太多，比如锁从模式上分为：共享锁（S）、更新锁（U）、排他锁（X）、架构锁（Sch-S、Sch-M）、意向锁（IS、IU、IX）、转换锁（SIX、SIU、UIX）、大容量更新锁（BU）；锁从粒度上分为：数据库锁、文件锁、表锁、堆锁、索引锁、页锁、键锁、区锁、行锁、应用程序锁、元数据锁；锁之间存在兼容性问题；锁会根据情况进行升级；锁控制不好会出现死锁；悲观锁的隔离性：未提交读、已提交读、可重复读、可序列化；乐观锁的隔离性：读提交快照隔离、快照隔离；闩（shuan）锁。。。随便列下就一大堆问题要说清楚需要花很大篇幅。还是抱着与前几篇文章的风格，仔细分析一个具体的问题——锁升级。

　　1、准备

　　有一个动态管理视图可以查看所有锁：sys.dm_tran_locks，还有一个动态管理视图可以查看哪些请求正在阻塞其他的请求：sys.dm_os_waiting_tasks

　　2、什么是锁升级

　　锁升级是指锁的粒度由细向粗转换。如：由行锁转成表锁。

　　3、需要锁升级吗？

　　一般来说，锁的粒度越小，并发性越好但是如果去锁定的东西多就需要的锁越多，这样会消耗SQLServer的cpu与内存。一个锁占用内存约为96字节，你算算如果用行锁去锁定百万千万的表需要多少内存。而且管理锁（创建锁、维护锁、销毁锁等）也是有代价的，会消耗cpu。 如果用一个大点的锁就将这些百万千万的锁合并成一个锁了，管理起来也方便消耗资源也小。

　　4、什么时候出现锁升级

　　SQLServer意识到锁定的页面或行数过大的时候发生。怎么意识到过大呢？由两种方法识别：请求用于的锁的数目超过锁数目临界值；锁管理器为单独一个查询消耗过多的内存超过内存临界值。有其他一个超过临界值，SQLServer就会试图升级。注意这里说的锁数据以及内存是值由同一个查询发生的，而不是总共的。这里说的临界值并不是固定的，SQLServer采用启发式算法去动态调整。

　　5、控制锁升级

　　SQLServer提供一些可以让我们控制锁升级的入口。在SQLServer2008中可以通过：

　　我们还可以通过在代码中显示指定pagelock、tablock提示，会强制SQLServer使用更粗的锁。不过这个设置不合理的话会导致并发降低。建议一般情况下不用，除非你很清楚这样带来的影响。