我们有一个大型的多用途应用程序，它在许多表上都有OBJECT和PAGE块。我们无法重新考虑设计，但需要减少影响客户端计算机性能的块。 我一直在考虑在一张桌子上禁用锁定升级，但需要知道它会对其他资源施加什么样的压力。磁盘i / o已经紧张。额外的单个锁需要比自动表锁更多的i / o吗？它会比我们的应用程序db更影响我们的系统数据库吗？ 我们不做全表更新/读取。每个请求只会处理表格的一小部分。
答案 0 :(得分：1)
我们有一个大型的多用途应用程序患有OBJECT和 PAGE 许多表上的块。
...
磁盘 i / o 已经紧张。 额外的单个锁需要比自动锁更多 i / o 表锁？
你误解了锁定升级问题，从你提出的问题的部分可以清楚地看出这一点。
锁定升级转为from rows to table或from pages to table（我排除了分区，因为它不是您的情况），所以如果现在您有页锁，那么 NOT lock escalation < / strong>即可。
除非您使用提示（rowlock，paglock），否则服务器会选择锁定粒度，如果选择page locks，则不会升级。如果它随后删除了所有page locks并将其替换为table lock，则表示lock escalation已发生。
第二件事是错误的，你认为锁与IO有关。这不是真的。锁存在内存中，与读取无关。您可以查看此文章，了解当锁更细化时CPU usage和query duration如何增加：Why ROWLOCK Hints Can Make Queries Slower and Blocking Worse in SQL Server。
您应该了解导致锁定升级的原因。
锁定升级阈值
未禁用锁定升级时会触发锁定升级 使用
ALTER TABLE SET LOCK_ESCALATION选项的表格，以及 当存在以下任一条件时：
- 单个Transact-SQL语句在单个非分区表或索引上获取至少5,000个锁。
- 单个Transact-SQL语句在分区表的单个分区上获取至少5,000个锁
ALTER TABLE SET LOCK_ESCALATION选项设置为AUTO。- 数据库引擎实例中的锁数超过了内存或配置阈值。
Lock Escalation (Database Engine)
因此，如果每个语句阈值达到5,000个锁，则应将操作拆分为较小的批处理。
如果您处于内存压力之下，禁用锁定升级将使您的情况更糟。
<强>更新
中找到了对锁的描述锁不是磁盘结构。您不会直接找到锁定字段 在数据页或表头上，以及跟踪的元数据 锁永远不会写入磁盘。锁是内部存储器结构： 它们消耗用于SQL Server的部分内存。锁是 由lock资源标识，这是资源的描述 锁定（行，索引键，页面或表）。跟踪 数据库，锁的类型以及描述锁定的信息 资源，每个锁在32位系统上需要64字节的内存 64位系统上128字节的内存。这个64字节或128字节 结构称为锁定块。 ...锁管理器维护一个锁哈希表。锁定资源， 包含在锁定块内的数据被散列以确定目标散列 哈希表中的槽。散列到同一个插槽的所有锁定块都是 从哈希表中的一个条目链接在一起。每个锁块 包含一个15字节的字段，用于描述锁定的资源。锁 block还包含指向锁所有者块列表的指针。每个 这三个州有一个单独的锁所有者名单。
希望它有所帮助。