我有這個傳統的作業，每5分鐘運行一次（它有一個SP正在做一個MERGE）。合併性能顯着變化從幾行到數千
它完美地跑了過去幾年......但是當源從1000行變更爲200,000行的合併...
沒有人經歷類似的問題開始了嗎？這項工作最多需要2分鐘的時間...現在有時需要2,3小時才能運行...
下面是最大合併執行計劃的截圖（SP總共有4個合併...）我嘗試使用執行計劃進行故障排除，但它是誤導性的......即使它說（相對於批處理）= 0％，這是佔用90％時間的代碼部分。 
感謝您的回覆;你已經真的很有幫助...
作業（存儲過程），涉及9個表，4個合併和大量的連接和合並後的更新...
（發佈這一切將是太長了）。
最後，我有問題縮小到SP的複雜性（整體做4個合併，9連接，並更新到最後3個表）：
而這一切都取決於這一點：
從[remote_server的]聲明@TableVariable作爲SF_OpportunityMerge
插入@ TableVariable 選擇（20列） 。[Salesforce中]。[DBO]。[機會] 其中UpdateDate> @LastUpdateDate
當這個選擇（這是大多數合併的基礎）返回10,20行...作業運行在幾秒鐘，當它返回50萬行將需要大約2個小時，這是非常有意義的，有沒有阻塞，沒有索引缺失（表變量有機會索引）...
工作內部，@TableVariable多次使用（包括合併），所以我得到的結果越多，它指數地增加其持續時間...
如果1000行的處理需要2分鐘，因此200,000行的處理應該（線性預測）6-7小時。性能似乎沒有顯着改變 - 這只是壞事，沒有其他。挖掘真正的問題：處理差1000行，你的sp工作了2分鐘。它在做什麼？你的桌子上有多少個索引？在GUID上是否有聚集索引？任何依賴於這些表的聚集視圖？觸發器？
請顯示合併代碼。可能的罪魁禍首是一個無條件的「匹配時更新集合」。 – JiggsJedi
像往常一樣回答這樣的問題，你需要包括一個[MCVE]（https://stackoverflow.com/help/mcve）：一個** M **，** C **完整，** V ** Erifiable ** E ** xample。 –