尝试运行维护计划时，我收到以下错误：
执行查询“”失败，出现以下错误：“无法重新组织表“”上的索引“”（分区 1），因为禁用了页级锁定。”
我们目前在此索引上启用了行级别锁定。我可以启用页面级别锁定，但我不确定会产生什么影响。
我的问题是：这两种锁定方案有什么区别，它们在现实世界（生产中）的后果是什么？
AskOverflow.Dev
尝试运行维护计划时，我收到以下错误：
执行查询“”失败，出现以下错误：“无法重新组织表“”上的索引“”（分区 1），因为禁用了页级锁定。”
我们目前在此索引上启用了行级别锁定。我可以启用页面级别锁定，但我不确定会产生什么影响。
我的问题是：这两种锁定方案有什么区别，它们在现实世界（生产中）的后果是什么？
维护计划必须尝试 ALTER INDEX REORGANIZE，这是一个在线操作。要删除碎片（页面不按顺序），必须锁定和移动页面，如果页面锁定已禁用，则这是不可能的。在没有页面锁的情况下进行碎片整理的唯一方法是锁定整个分区，这对于 REORGANIZE 是不可能的，因为它只在线。
您需要掌握记录和页面是什么来评估禁止特定锁定类型的影响。如果您不熟悉 SQL Server 存储内部结构，请从Anatomy of a Record和Anatomy of a Page开始。简单地说：
如果您要更改允许的锁类型：
我知道在两种情况下禁止锁定类型是有益的。并不意味着没有其他人，希望其他人会举例说明。
一个经常访问的查找表，但不经常更改- 通过禁用页级和行级锁，所有读取器都将获取共享表锁。这更快/更便宜，而不是通常在表上的意图共享，然后是页面上的意图共享，最后是特定行或行上的共享锁。
防止特定的死锁情况- 如果您遇到由并发进程获取经常在同一页上的锁而导致的死锁，则不允许行锁会导致取而代之的是页锁。然后一次只有一个进程可以访问该页面，另一个必须等待。
第一个例子是微优化，不太可能在典型系统上产生可衡量的收益。第二个将解决特定的死锁场景，但可能会引入意想不到的副作用，例如在不同的代码部分中杀死并发。难以全面评估影响，谨慎接近！
默认情况下两者都启用，并且不应在没有正当理由的情况下更改此设置。
大概什么都没有。我敢肯定 MS 比你我更了解
我曾在大容量 OLTP 系统上工作过，但从未觉得需要更改设置。应该重试死锁，因为无论如何它们都会发生
引用SQL Server 存储引擎博客“SQL2005 中的锁升级”无论如何都值得一读。
我认为，如果您只强制行锁，那么您将消耗可以在其他地方更有效地使用的资源。如果您的负载足够高，这很重要，那么为什么要消耗内存？博客文章对此进行了介绍
我怀疑这背后有一些迷信，就像这些：