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

Posted 2023-04-14

【中文标题】存储过程超时，而后续运行需要 1/6 的时间 [关闭]

【英文标题】：stored procedure times out while subsequent runs take 1/6 the time [closed]

【发布时间】：2011-10-04 18:24:01

【问题描述】：

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

在随后的运行中，“Last Select”语句以及随后的整个批次所花费的时间要少得多。尤其令人好奇的是，随后的运行使用了更多的配置文件（第二次运行 15,000 个新配置文件，第三次运行 25,000 个新配置文件）。

比较查询计划，我发现 10000.trc 和 25000.trc 之间存在一些有趣的差异。在“最后选择”之前的步骤中可以看到以下两种情况

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

慢速运行在最终选择期间使用了许多聚集索引扫描和聚集索引查找，而快速运行则没有。慢速运行还使用“连接”步骤（在快速运行中未找到），该步骤附加多个表以生成输出表。

这里是时代的总结；

感谢任何帮助。谢谢！

【问题讨论】：

您使用的是什么 RDBMS 和该 RDBMS 的版本？

SQL Server 2005 管理工作室 9.00.1399.00

【参考方案1】：

一般来说，并行运行的查询会运行得更快，您可以使用一些提示来强制查询并行运行，但您在使用它们时要谨慎，因为 SQL Server 可能会做出糟糕的性能决策。

索引搜索也比索引扫描快，所以它们是你应该努力的。

虽然上面列出的都是一般性的指针，但如果你能给出最后一个 select 语句，那将真的很有帮助。再加上所涉及的表格的粗略大小。