不同版本的 SQL Server 的查询性能是否不同？

Question

我在我的存储过程中为 3 个不同的表触发了 3 个更新查询。每个表包含近 2,00,000 条记录，所有记录都必须更新。我正在使用索引来加快性能。它与SQL Server 2008配合得很好。执行一个存储过程只需12 到 15 分钟。（在所有三个表中在 1 秒内更新近 1000 行）

但是当我使用SQL Server 2008 R2运行相同的场景时，存储过程需要更多时间来完成执行。大约需要55 到 60 分钟。（在所有三个表中在 1 秒内更新近 100 行）。我找不到任何原因或解决方案。

我也用SQL Server 2012测试了相同的场景，但结果与上面相同。

这是我在存储过程中的 3 个表更新查询。

if (select COUNT(*) from table where conditions)>0

begin

    update table1
    set Coulmnname= @ColumnName
    where Conditions

    update table2
    set Coulmnname= @ColumnName
    where Conditions

    update table3
    set Coulmnname= @ColumnName
    where Conditions

end 

执行计划 图 1 图 2

Answer 1

是的，它会有所不同。每个版本都会对优化器、代码路径、缓存算法等进行调整。我希望更高版本的运行速度比早期版本快。

我正在使用索引来加快性能。

不你不是。如果表中的每一行都必须更新，那么索引充其量是无关紧要的。如果索引包含您正在更新的列，则索引的页面也必须更新，从而导致额外的写入开销。

您是否检查了三个不同实例的查询计划？我的猜测是 2008R2 的可用内存较少，优化器选择溢出到 TempDB，或者操作系统强制分页到虚拟内存页面文件。或者可能是 8R2 实例的事务日志文件开始时很小，而您看到的是自动增长的产物，可以容纳 600 万条日志记录。

在处理这么多记录时，我总是会向我的开发人员推荐批处理。 更新集群键序列中的前 N ​​条记录。 然后再做下N，依此类推，直到所有2M都做完。可以更改“N”以在您的特定安装中提供最佳行/分钟，尽管数以万计往往是正确的。通过这种方式，日志文件保持较小，事务锁定减少，并且在发生故障时可以重新启动。