SQL（服務器）更新性能

Question

我有限的SQL知識提示這篇文章！

我有一個運行一系列更新的存儲過程。
有6個更新語句，可以很好地混合到一個大的更新語句中，但我不知道這對性能意味着什么。

表基礎：打了6個表。 其中3個記錄永遠不會超過5000條記錄，其中3條記錄無限增長（目前約有1-2百萬條記錄，正確編制索引等）。 加入所有表並執行一個大規模的更新聲明與將其保持為6個單獨的更新是否有速度優勢？

我正在尋找最有效的方法來做到這一點，即使它削減了第二次。

謝謝。

編輯：

我向所有人道歉。 我只更新一個表，但驗證來自所有6的數據以更新一個表。 （即檢查table2.somevalue是否為空，然后將table1中的記錄標記為“error”）

Answer 1

在T-SQL中甚至不可能（在單個UPDATE語句中同時更新多個表）。

來自BOL ：

TABLE_NAME

是要更新的表的名稱。 如果表不在當前服務器或數據庫中，或者不屬於當前用戶，則可以使用鏈接服務器，數據庫和所有者名稱限定名稱。

和

VIEW_NAME

是要更新的視圖的名稱。 view_name引用的視圖必須是可更新的。 UPDATE語句所做的修改不會影響視圖的FROM子句中引用的多個基表。

Answer 2

如果可以將它們組合起來，那么是的，你應該將它們組合起來。

如果要從單個表中更新多個列，請將它們組合為：

UPDATE mytable
SET foo = bar, fizz = buzz, whiz = bang
WHERE zing > 2081

代替

UPDATE mytable SET foo = bar   WHERE zing > 2081
UPDATE mytable SET fizz = buzz WHERE zing > 2081
UPDATE mytable SET whiz = bang WHERE zing > 2081

這幾乎是效率的3倍，因為它只需要通過一次表。

不同表中字段的更新必須單獨進行（如Cade Roux所述，它甚至不可能同時進行）。

即使您使用的是復雜連接，也只能一次更新一個表。 就像是：

UPDATE AccountHistory
SET LastPurchaseDate = i.PurchaseDate
FROM Account a
INNER JOIN AccountHistory h ON a.AccountID = h.AccountID
INNER JOIN Invoices i ON i.AccountID = a.AccountID
WHERE i.PurchaseDate > '2009-11-30'

即使通過連接訪問源數據，也只在此處更改AccountHistory。

Answer 3

您無法使用提供的數據得到一個好的答案 - 您需要了解每個更新是否已對索引編制索引以及組合對更新復雜性的影響。

我認為6次更新（如有必要，在事務中）比1次大更新更容易理解 - 所以這是一個更好的解決方案，您可以盡可能快地優化每次更新。

JRud評論很好 - 您可以隨時嘗試並比較時間。

Answer 4

當查詢來自[遠程]客戶端時，通常可以通過對查詢進行分組來實現顯着的性能改進。 在您的情況下，多個查詢來自存儲過程，因此很容易就是本地請求，並且如果有的話，組合它們的好處將不會很大。

此外，在檢查SQL文檔時， 在UPDATE的情況下，不可能編寫一次修改多個表的查詢 ...

但是，由於您似乎在尋求最有效的方法，因此您需要嘗試各種可能性 （在一組有代表性的數據輸入下）以查看特定更改的效果。 如果沒有關於您的具體情況的更多細節，很難提供更有針對性的信息。

一個小而通用的提示：
提到“正確索引”引用“大”表，提醒一下，當談到UPDATE（以及更常見的寫操作，如刪除和插入）時，索引可能更像是一種資產，性能 - 明智的。

Answer 5

即使有，我也不建議修改基本表模式以將性能提高一小部分。 如果改變會在性能上產生很大的變化（如雙倍或三倍），那么在性能至關重要的情況下，它可能是值得的，但是，

對於幾乎所有現代數據庫包，還有許多其他可用的技術可以在不更改基本表模式的情況下提高性能。 您可以添加為應用程序使用的查詢類型定制的索引。 在其他技術中，您可以添加索引視圖（Oracle中的物化視圖）。 您可以垂直和/或水平分區表。 在SQL Serve中，您可以“PIN”小表，以便它們始終保留在內存中。

Answer 6

您是在嘗試提高存儲過程的整體性能還是縮短UPDATE的時間？

如果我更擔心並發（減少鎖定時間）而不是整體性能，我會將鍵值選擇為變量或臨時表。 然后，我在UPDATE中使用變量或臨時表。 “焦點”可以顯着提高UPDATE性能。

警告：使用此方法需要很好地理解系統的工作原理。 這種方法的最大風險是增加死鎖的可能性。