在执行计划中使用 Eager Spool 和 Sort 运算符进行索引更新

Question

对大型表执行 UPDATE 语句后，执行计划会显示包含更新列的索引（所有非聚集索引）的更新。

在每次索引更新之前，都有一个 Eager Spool 操作符，后面跟着一个非常昂贵的 Sort。

总的来说，索引的更新消耗了大约50%的执行时间。

有没有办法优化索引并最小化成本？

Answer 1

总的来说，索引的更新消耗了大约50%的执行时间。

不是，显示的百分比是根据 SQL Server 成本模型每个操作员估计成本的比例。这些由优化器在内部使用来在计划替代方案之间进行选择 - 它们并不意味着显示现实世界的性能，而且通常也不会。

要获取运行时性能数据，您需要运行相当现代版本的 SQL Server 和 SSMS。有关详细信息，请参阅SQL Server Tiger 团队的新显示计划增强功能。

仅从计划图形无法判断您是否应该关注所选的更新计划形状。仅从线条的粗细来看，它看起来确实应该很快。

您看到的计划是一个广泛的（或每个索引）更新计划。这会将所有非聚集索引更新所需的所有更改信息收集到表假脱机中，然后分别重播每个索引的适当更改数据。排序运算符用于确保按键顺序将更改应用于索引，以优化顺序 I/O。您可以在我的文章优化更改数据的 T-SQL 查询中阅读有关更新计划形状的更多信息。

正如文章中提到的，SQL Server 通常可以考虑一个狭窄的（每行）更新计划，其中所有非聚集索引都由聚集索引更新运算符维护。从所提供的信息中无法判断为什么优化器没有（或不能）在您的情况下选择该选项。

如果您在查看运行时性能后发现有必要，欢迎您提出有关更新查询性能调整的后续问题。您必须提供足够的详细信息，以便有适当资格的人来回答。这通常包括表和索引定义以及运行时（“实际”）执行计划。有关数据库相关问题，请参阅帮助中心中的如何创建最小、完整且可验证的示例。