可能拖延UPDATE x SET y = NULL語句

Question

我們已棄用某個功能並正在清除一些數據。在完全刪除需要太多即時應用程序開發的列之前，我們只需簡單清除其包含的數據（應用程序支持的數據）。

但是，一個簡單的UPDATE foo SET bar = NULL似乎異常昂貴。在數據庫的測試副本中，在我們取消它之前，它運行了三個多小時。

我們再次嘗試使用表鎖和READ UNCOMMITTED隔離級別進行查詢，但無濟於事（在另外三個小時後取消）。

該表包含大約112000行，每行的列包含大約41400字節（所以我們正在清除大於4GiB的數據）。雖然它有相當多的數據，但我們發現將剩餘列複製到新表中，刪除舊錶並重新命名新表會實際上更快。請注意，我們不知道要花多少時間才能完成UPDATE，否則我們在3小時後停止，但可能每天5,6,12。

該表在這些操作過程中的併發訪問精確度爲零。

有人會對我們的方案有任何建議嗎？ copy + drop + rename是否是最好的選擇？如果是的話，還有什麼特別的建議使它儘可能安全？

對我們來說，一個可能天真的假設是DBMS將能夠在正常的UPDATE聲明的幕後制定一個複製/交換策略，如果給出足夠鬆散的提示。可能嗎？

Answer 1

我們結束了複製和交換表。

評論中的question linked by Stephan包含一些有用的指導，說明如何在操作過程中保持數據集在線。特別是參見Mitch Schroeter的this answer，它基本上建立了在轉移發生時新舊桌子結合的觀點。

因爲我們不需要保持數據集在線，所以這是過度的（特別是考慮到其他數據集非常小）。相反：

CREATE TABLE _foobar (id INT IDENTITY PRIMARY KEY, foo INT, bar INT NULL); 
SET IDENTITY_INSERT _foobar ON; 
INSERT _foobar (id, foo, bar) SELECT id, foo, NULL FROM foobar; 
SET IDENTITY_INSERT _foobar OFF; 
DROP TABLE foobar; 
EXECUTE sp_rename '_foobar', 'foobar'; 

整個操作耗時14秒，這似乎很難擊敗我們的場景。

一些提示/評論：

• 確保CREATE TABLE語句產生匹配（例如使用像VS或SSMS工具）的模式。
• 不要忘記IDENTITY列。這意味着您需要爲INSERT語句顯式編寫列列表，當然還需要爲該表設置IDENTITY_INSERT。詳情請參閱MSDN documentation。

結論：

• 這似乎是根據this有分割在多個交易正常UPDATE交易在更高的層次來管理一致性，沒有簡單的方法。正如那裏和HABO所建議的那樣，所有解決方案似乎都需要掃描每個批次的請求謂詞，或者使用臨時表來一次存儲與謂詞匹配的行的鍵，並將其用於每個批次（其中應該總是更快，因爲PK始終是索引的）。
• 似乎沒有簡單的方法來執行復制/交換，同時保持聯機操作。同樣，請參閱this以瞭解手動設置聯合視圖的方法。
• 如果數據集的其餘部分非常小（快速完整地複製）並且不需要保持聯機狀態，則可以使用上面更直接的方法。免責聲明：如果您有DBA，請諮詢您的DBA，如果您不能100％確定自己在做什麼，這可能會很危險。