Sql-Server
更新“實時”表上數據的最佳實踐
設想：
我正在執行一個連接到 SQL Server 作為數據後端的使用者應用程序。在正常的一天中，與應用程序關聯的表中的數據可能會經常更改，目前擁有 1500 萬多條記錄（並且還會進一步增長）。但是，只有在整個更新語句成功完成後，應用程序才能應用和訪問 in- 和 upsert，並且永遠不會發生臟讀。
為了能夠為應用程序提供對錶的持續可訪問性，我使用了一個輔助表，在該表中進行實際的更新和索引重建，因此主表保持解鎖狀態。完成後，表只是交換。
我還調查了：
- 啟用已送出的讀取快照（不過，它似乎相當消耗資源）
- 使用水平分區
問題：
由於我對此相當陌生，並且不太確定是否有任何“更好”的方法來解決這種情況（性能、數據庫原生、設置等），因此值得深思。
更新：
- App的營業時間為9點至5點
- Azure 上託管的 SQL Server Enterprise (AzureSQL)
啟用已送出的讀取快照（不過，它似乎相當消耗資源）
您是否使用您的工作負載版本對其進行了測試？如果沒有，我建議這樣做。如果您可以使用 SQL Server 中已經內置的旨在解決您的問題的技術，您通常會做得更好。知道 Azure SQL 數據庫預設使用 RCSI，您可能會感覺更好。如果它適用於所有這些數據庫，那麼它也許適用於您的數據庫。
通過在數據庫上啟用快照隔離，您可以在不更改應用程序行為的情況下測試 RCSI 的性能影響。這將創建 RCSI 所需的所有相同 tempdb 行版本，但快照隔離級別將僅用於選擇加入它的程式碼。Kendra Little 有一篇博文，其中包含更多詳細資訊。
對於索引維護，我假設您使用的是標準版？如果是這樣，RCSI 將不會真正幫助你。您需要在使用者活動較少的時間段（您的應用程序是 24/7？）或在維護視窗期間進行索引重建。這可能看起來不方便，但這是每個使用標準版的人都會處理的問題。您目前可能比必要更頻繁地重建索引。