存储过程超时，而后续运行需要1/6的时间

Question

所以我在一个特定的生产环境中运行这个存储过程非常慢（和超时）。此存储过程生成xml的配置文件数据。在所有其他环境中，sp运行速度非常快。在特定环境中跟踪程序后，我发现最终的“SELECT”语句占用了总时间的96％（应该低于30％）。该语句涉及多个SELECTS，UNIONS和JOINS。我将此称为“最后选择”声明。

在后续运行中，“最后选择”语句以及随后的整个批次花费的时间要少得多。特别令人好奇的是，后续运行使用了更多的配置文件（第二次运行时为15,000次，第三次运行时为25,000次）。

比较查询计划，我发现10000.trc和25000.trc之间存在一些有趣的差异。在“最后选择”

之前的步骤中可以看到以下两种情况

1. 更快的运行（25K）利用涉及并行性的许多操作。在慢速运行中，我没有看到任何涉及并行性的操作。
2. 更快的运行使用“哈希匹配”和“合并连接”用于内部和外部联接（而不是嵌套循环）。除了少数例外，慢速运行似乎总是使用嵌套循环。

慢速运行在快速运行的最终选择期间使用许多聚簇索引扫描和聚簇索引搜索。慢速运行也使用“连接”步骤（在快速运行中找不到），它附加多个表来生成输出表。

这是时代的总结;

感谢任何帮助。谢谢！

Answer 1

通常，并行运行的查询运行得更快，有一些提示可以用来强制执行查询并行运行，但是你要谨慎使用它们，因为它可以让SQL服务器做出糟糕的性能决策。 / p>

索引搜索也比索引扫描更快，因此它们是您应该努力的目标。

虽然上面列出的是一般指针，但如果您可以发布最后一个选择语句，那将非常有用。另外，给出了相关表格的粗略大小。