批量插入時刪除/重建索引

Question

我已經獲得了超過7000萬條記錄的表格;我剛剛發現開發人員在批量插入前刪除索引，然後在批量插入結束後再次創建。存儲過程的執行時間將近30分鐘（做下降索引，做批量插入，然後重新創建索引

建議：這是一個很好的做法，可以從擁有超過70多萬條記錄的表中刪除INDEX並且增加3-4萬元每一天。

這將有助於通過插入不會放棄指數散裝前提高性能？

是什麼，而在大表做批量插入應遵循的最佳實踐。

謝謝，關心

Answer 1

與SQL Server中的所有內容一樣，「它取決於」

在插入期間維護索引時存在開銷，並且在插入後重建索引時出現開銷。明確確定哪種方法導致更少開銷的唯一方法是嘗試它們並對其進行基準測試。

如果我是一個博彩人，我會把我的賭注放在索引的位置上，但是我沒有完整的畫面來進行有根據的猜測。再一次，要確定的唯一方法就是嘗試兩種選擇。

一個關鍵的優化是確保您的批量插入按聚簇鍵順序。

---

如果我正確地讀你的問題，該表是負荷期間幾乎關閉的限制（鎖定），這是一個問題。

如果您的主要目標是增加可用性/減少阻塞，請嘗試採用A/B表方法。

的A/B方法分解如下：

給定一個名爲表 「MyTable的」 你實際上有兩個物理表（MyTable_A和MyTable_B）和一個視圖（MyTable的）。

如果MyTable_A包含當前「活動」數據集，則您的視圖（MyTable）將從MyTable_A中選擇所有列。同時，您可以在MyTable_B（包含MyTable_A的數據副本以及您正在編寫的新數據的副本）上擁有全局信息。一旦MyTable_B被加載，索引並準備就緒，請更新您的「MyTable」視圖以指向MyTable_B並截斷MyTable_A 。

這種方法假定您願意增加I/O和存儲成本（在您的情況下顯着）來維護可用性。它還假定你的大桌子也相對靜止。如果你遵循這種方法，我會推薦第二個視圖，就像MyTable_old指向非活動表（即，如果MyTable_A是當前演示表並由MyTable視圖引用，MyTable_old將引用MyTable_B），您將更新MyTable_old視圖在同一時間更新MyTable視圖。

---

根據您插入數據的性質（和你的SQL Server版本/版），你也可以利用分區（MSDN blog on this topic.）