存儲過程超時，而隨後的運行需要1/6的時間

Question

所以我有這個存儲過程在一個特定的生產環境中運行非常緩慢（並超時）。此存儲過程生成一個xml的配置文件數據。在所有其他環境中，sp運行得非常快。在特定環境中追蹤程序後，我發現最終的「SELECT」語句佔總時間的96％（應該低於30％）。此聲明涉及多個SELECTS，UNION和JOINS。我將這稱爲「最後選擇」聲明。

在後續運行中，「最後選擇」語句以及隨後的整個批處理花費的時間更少。特別好奇的是，後續運行使用了更多配置文件（第二次運行中新增15,000個，第三次運行中新增25,000個）。

比較查詢計劃，我發現10000.trc和25000.trc之間有一些有趣的差異。在「最後選擇」之前的步驟中看到以下兩者：

1. 更快的運行（25K）利用許多涉及並行性的操作。在緩慢運行中，我沒有看到任何涉及並行性的操作。
2. 更快的運行使用內部和外部聯接（而不是嵌套循環）的「哈希匹配」和「合併聯接」。除了少數例外，緩慢運行似乎總是使用嵌套循環。

緩慢運行使用了許多聚集索引掃描和聚集索引搜索期間的最後選擇，快速運行沒有。慢速運行也使用「連接」步驟（在快速運行中找不到），該步驟附加多個表以生成輸出表。

下面是時間總結;

任何幫助表示讚賞。謝謝！

Answer 1

一般來說，並行運行的查詢運行速度會更快，您可以使用這些提示來強制查詢並行運行，但您希望謹慎使用它們，因爲它可以使SQL Server做出糟糕的性能決定。

索引查找也比索引掃描更快，因此它們是您應該爭取的。

儘管上面列出的是一般性指針，但如果您可以發佈最後一條select語句，它確實會有所幫助。另外給出涉及表格的粗略大小。