爲什麼SQL Server Management Studio中的這個sql腳本太慢了？

我有一個SQL腳本可以將大約8000行插入到TABLE變量中。爲什麼SQL Server Management Studio中的這個sql腳本太慢了？

插入該變量後，我使用WHILE循環遍歷該表並執行其他操作。該循環可能是60行代碼。

如果我運行TABLE變量插入部分腳本，沒有while循環，大約需要5秒。那很棒。

但是，如果我運行整個腳本，大約需要15分鐘。

這裏是很有趣，而且我想不通：

當我運行了整個劇本，我沒有看到任何報表打印，直到多分鐘到腳本。

然後，一旦它找出要做什麼（大概），它會將插入操作運行到表var，執行循環，並且所有操作都相當快。

然後，在循環結束時，或者甚至在循環結束後，它會持續多個分鐘並掛起。最後，它循環播放循環後面的腳本的最後幾行。

我可以解釋插入過程中所花費的所有時間，然後在循環中佔用所有時間。但我無法弄清楚爲什麼它會在腳本的前幾分鐘和結尾處掛起。

對於踢腿，我在插入到臨時表後添加了一條GO語句，並且所有一切都按照您的預期運行;然而，我不能這樣做，因爲我需要這個變量，而GO語句顯然會殺死那個變量。

我相信我會停止使用表變量，並與真正的表一起去，以便我可以發出GO，但我真的很想知道這裏發生了什麼。

想了解SQL Server在那段時間內要做什麼？

謝謝！

來源

2010-11-05 marc esher

你能提供腳本嗎？如果不仔細觀察，它很難回答。 – 2010-11-05 21:53:49

我可以，但它是@ 17000行！我將編輯併發布相關位，儘管 – 2010-11-05 22:02:12

明白了......問題不在於插入或循環......它是循環之後的部分。我不知道爲什麼SQL服務器花了這麼長時間，但一旦我擺脫了（這是一個重大的「IN」聲明），一切都很順利。 – 2010-11-05 22:08:39

如果您正在使用表變量，您是否可以嘗試用臨時表替換它並查看性能是否有任何變化？

如果可能，請發佈代碼，以便可以分析可能的感興趣區域。

來源

2010-11-05 21:58:48

您可以始終從Activity Monitor或sys.dm_exec_requests視圖中檢查腳本正在執行的操作。該腳本將被阻止，您將能夠看到wait_type和wait_resource列中的屏蔽內容。

有幾個可能的罪魁禍首，如等待行鎖或表鎖，但從我懷疑是數據庫或日誌增長事件的問題的描述。一旦數據庫足夠大，這些數據往往非常昂貴，默認的10％增長意味着GB的增長。如果是這種情況，請嘗試按所需大小預先設置數據庫的大小，並確保爲數據文件啓用了Instant File Initialization。

來源

2010-11-05 22:09:09

檢查[此]（http://dba.stackexchange.com/questions/75546/database-sql-script-very-very-slow-string-manipulation-over-700k-rows）也是一樣的作者。 – stom 2015-12-02 14:04:30

從你的問題的措辭，這聽起來像你使用光標循環通過表。如果是這種情況，在啓動循環之前發出「SET NOCOUNT ON」命令將有所幫助。

在之前的答案中提到了表變量，但作爲一般規則，如果您的行數超過了幾行，則應該真的使用臨時表。

來源

2010-11-05 22:14:53

打印件被緩衝，因此您無法從中判斷打印效果。
使用RAISERROR ('Message', 0, 1) WITH NOWAIT立即查看輸出。

爲了理解過程在做什麼，我首先調用sp_who2幾次，查看感興趣進程的值：是不是被阻塞，等待類型是什麼，如果有的話，等等上。此外，僅查看服務器硬件負載（CPU，磁盤活動）可能會有幫助（除非有其他活動進程）。

請發佈一些代碼。 Table var定義和循環就足夠了，我相信，不需要INSERT的東西。

來源

2010-11-05 22:34:02 VladV

爲什麼SQL Server Management Studio中的這個sql腳本太慢了？

回答

相關問題