沒有更新的SQL快速插入

我們在SQL Server 2008數據庫中使用單個表進行審計。沒有更新的SQL快速插入

單表體系結構很好地工作，很容易查詢，適應模式更改。

但它是整個數據庫的主要瓶頸。所有INSERTS和UPDATES都必須通過審覈表。

我們已經對SELECT語句使用了NOLOCK HINT。

由於此表沒有更新，是否有任何改善INSERT語句吞吐量的建議？

來源

2009-08-22 pkario

確保您在表格上具有INT（或BIGINT）IDENTITY主聚簇索引！最好不要使用其他索引（如果可能的話） - 這會降低插入速度。

這是一個常見的誤解，即由於表只需要INSERT並且幾乎沒有讀取，所以應該自己「保存」主密鑰的麻煩。

與SQL Server索引的女神，金佰利特里普，解釋了她出色的博客文章The Clustered Index Debate continues：

鑲片在羣集表更快（但僅限於「正確」的聚集表），比與一個堆相比。這裏的主要問題是，IAM/PFS中的查找確定堆中的插入位置是比聚簇表（其中插入位置已知，由聚簇鍵定義）慢。當插入表插入表其中定義順序（CL）和其中的順序是不斷增加。

所以一個右聚集索引可以加快你的插入，在這裏是指靜態的（不會改變），獨特的，儘可能小（INT或BIGINT），最好不斷增加（無頁拆分和因此沒有性能損失）。

此外，如果您的表只獲取插入並且沒有更新/刪除，則應確保在聚集索引上使用100％FILLFACTOR以完全填充這些SQL服務器頁面。

馬克

來源

2009-08-22 15:25:41

我正在沿着這些路線工作。我有一個IDENTITY CLUSTERED PRIMARY KEY，所以INSERTs真的是APPENDs在最後一頁。 100％的填充因子是一個很好的觸摸。我正在考慮每月進行一次維護，將記錄移到「永久性」歷史記錄表中，以便主表永遠不會變大。 – pkario 2009-08-22 15:46:11

好吧，如果你的索引不斷增加，即使表的大小真的不是什麼大問題（顯然除了選擇） – 2009-08-22 15:49:37

唯一的建議，我會做是：

確保您從編寫非字符串值儘可能
通過存儲過程封裝你寫入審計
搶任何其他數據存儲過程調用或
考慮在您的審計存儲過程中使用一個單獨的僅用於此目的的視圖。確保其連接儘可能少。這個視圖將用於查找審計消息的PK等，當試圖找到您的字符串數據的FK。
不是一個建議，但一個事實：較少的索引意味着更快的插入+較慢的選擇。
考慮將舊的審計行歸檔到另一個表中。保持審覈表儘可能小。將這些較舊的審計行移到另一個表。對於報告/查詢，請創建一個視圖，該視圖將join或union「實時」和「較早」的審覈。

來源

2009-08-22 15:16:12

如果你只附加到審計表和運行要總是最後執行表掃描報告，認爲在表中刪除任何索引。

來源

2009-08-22 15:29:29

沒有更新的SQL快速插入

回答

相關問題