在表更新之前收集流运算符导致串行更新导致 SQL Server 2017 中长时间运行的查询

如何解决在表更新之前收集流运算符导致串行更新导致 SQL Server 2017 中长时间运行的查询

我有一个长时间运行的存储过程，里面有很多语句。经过分析，确定了花费最多时间的少数语句。这些语句都是更新语句。

查看执行计划，查询在几秒钟内并行扫描源表，然后将其传递给收集流操作，然后传递给

这有点类似于下面的内容，我们看到索引创建语句的相同行为也导致了缓慢。

https://brentozar.com/archive/2019/01/why-do-some-indexes-create-faster-than-others/

表有 6000 万条记录，并且是一个堆，因为我们要进行大量数据加载、更新和删除。

读取源代码不是问题，因为它会在几秒钟内完成，但串行发生的实际更新需要花费大部分时间。

解决方法

一些尝试的建议：

如果您在目标表上有索引，在之前删除它们并在之后重新创建应该可以提高插入性能。

向您要插入的表添加 insert into [Table] with (tablock) 提示，这将使 sql server 能够以独占方式锁定表并允许插入也并行运行。

或者，如果这不会产生改进，请尝试向查询添加 maxdop 1 提示。

你多久更新一次这个堆中的行？因为，与聚集索引不同，堆将使用 RID 来查找特定行。但问题是（除非您专门重建它）当您更新一行时，最后一行仍将保留在原来的位置，现在改为指向新位置，从而增加每次执行所需的查找次数连续更新。我真的不认为这会在这里受到影响，但是如果您在表上添加聚集索引并查看更新时间如何受到影响，您是否可以看到会发生什么？

另外，我不认为你在桌子上有一些沉重的扳机，也做了很多事情，对吧？

此外，由于您指的是 Brent Ozar 的一篇文章，他确实主张将更新分成每次不超过 4000 行的批次，因为这已被证明是最快的，并且会低于 5000 行更新期间会发生 X 锁。