禁用锁升级的缺点

Question

我有一个名为MyFactTable的表，如下所示：

Create table MyFactTable
(
RunID int,
Key2 int,
Key3 int,
Key4 int,
….
Value2 numeric,
Value3 numeric,
Value4 numeric,
….
)

它还包括：

• RunID上的非唯一聚集索引(非唯一索引，因为RunID可以有数十万行与其关联)；
• 几个其他非聚集索引，以帮助查询；

运行ID是完全相互隔离的，通常我将有多个进程插入到这个表中(显然具有不同的RunID)。问题是，我似乎无法并行运行插入，这意味着当进程A插入到表中时，进程B也会被阻止这样做。

在95%的情况下，这并不是什么大问题，因为大多数RunID都非常小(少于50万行)，它们只会锁定表几秒钟，但最终会启动一个更大的任务(20+ Millon行)，并锁定表几分钟，从而阻止所有较小的进程完成。

我认为这是因为试图插入到表中的第一个进程是获取表锁，因此我使用以下命令禁用了锁升级：

ALTER TABLE MyFactTable  SET (LOCK_ESCALATION=DISABLE)

这确实解决了问题，但现在我想知道这样做可能会带来什么后果。

有没有人遇到过这样的情况，愿意分享他们的经验。

第二点，我还能用什么其他可能的解决方案呢？我考虑过对表进行分区，并将所有小的运行放在一个分区中，将所有的大运行放在另一个分区中(我不在乎大的运行是否会阻塞自己，我只想确保小的不被大的分区阻塞)。你对此有什么看法？

我想值得说的是，这个表从来没有更新过，一旦插入了RunID，它就只会被查询(所以不再使用相同的RunID进行插入)，最后通过清理过程删除它。

谢谢，迭戈

Answer 1

摘要：

对于插入/选择，除某些资源使用情况外，我不认为禁用锁升级有任何问题。

通常，插入不会锁定表，除非您正在执行bulk loading或insert select。

当您禁用锁升级时，除了使用更多的内存外，我不认为插入有任何问题，除了使用更多的内存外，使用的内存将是

锁在SQLServer中使用96字节的内存，所以当表为每一行持有行锁时，所使用的内存与行数成正比*96字节

现在来讨论其他事务的事务一致性，例如当禁用Lock_escalation时，在同一表上插入、更新/删除。

如果锁不兼容，则不会出现事务不一致，因为它们只会被阻塞。

最后，我在下面的示例中看到了其他DML事务.See的性能问题，以获得更多详细信息。

Table1有1000页，每页有100行，总共有100000行，当您将数据插入到这个表中时，每一行都将使用'X‘锁锁定，直到事务有completed.so为止--删除/更新必须检查每一行，以确定它是否可以保持锁或not..Earlier，它可以检查更高级别的锁

我不确定删除/更新是否会在第一次找到不兼容锁的行时立即被阻塞，或者它将继续检查，因为我没有Test2008实例来测试currently.will的更多细节