索引SQL SERVER中的大表

Question

我有一個大表（超過10萬條記錄）。此表大量用於應用程序中的搜索。所以，我不得不在表格上創建索引。但是，在表中插入或更新記錄時，我遇到性能下降的問題。這很可能是因爲重新計算索引。

有沒有辦法改善這一點。

在此先感謝

Answer 1

您可以嘗試通過減少索引中的填充因子來減少頁面拆分的次數（在索引中）。默認情況下，填充因子爲0（與100％相同）。所以，當你重建你的索引時，頁面會被完全填滿。這適用於未修改的表（插入/更新/刪除）。但是，當數據被修改時，索引需要改變。填充因子爲0時，可以保證獲得頁面拆分。

通過修改填充因子，您應該在插入和更新時獲得更好的性能，因爲頁面不總是必須分割。我建議你用填充因子= 90來重建索引。這會使頁面的10％變爲空，這將導致更少的頁面拆分並因此減少I/O。90可能不是最佳使用價值，所以這裏可能會涉及一些「試錯」。

通過使用填充因子不同的值，你的SELECT查詢可能會稍微慢一些，但有90％的填充因子，你可能不會注意到太多。

Answer 2

我們就需要看你的索引，但可能肯定的。

有些事情要記住的是，你不想只在每列上放一個索引，而且你通常不希望每個索引只有一列。

要做的最好的事情是，如果您可以記錄某些實際搜索，跟蹤用戶實際搜索的內容，並創建針對這些特定類型搜索的索引。

Answer 3

這是一個典型的工程權衡......可以使鏟更輕或更強壯，從來都......（直到在材料科學的突破。）

更多的指數意味着更多的DML維護手段更快的查詢。

更少的索引意味着更少的DML維護，意味着更慢的查詢。

有可能您的某些索引是多餘的，可以合併。

除了Joel寫的，你還需要爲DML定義SLA。它可以慢一點，你注意到它減慢了速度，但是它對你所取得的查詢改進是否真的很重要...... IOW，有一個弱的輕鏟可以嗎？

Answer 4

有許多解決方案，你可以選擇

a）您可以分區表

b）考慮在夜間在非高峯時間分批進行更新（像）

三）由於工程是一種權衡的平衡行爲，您將不得不選擇哪個更重要（選擇或更新/插入/刪除）以及哪個操作更重要。假設你並不需要實時結果的「插入」，你可以使用SQL Server服務中介對這些作業進行「不太重要」的操作異步

http://msdn.microsoft.com/en-us/library/ms166043(SQL.90).aspx

感謝 -RVZ

Answer 5

如果你有一個聚集索引，是不是對的身份數字字段，重新排列頁面可以減慢你的速度。如果是這種情況，您可以通過將其設置爲非聚集索引來加快速度（比沒有索引更快，但趨於比聚集索引慢一點，所以您的選擇可能會減慢，但插入會改進）

我發現用戶更願意稍慢的插入或更新容忍較慢的選擇。這是一條通用規則，但如果它變得難以接受（或者更糟），那麼沒有人能夠很好地處理這個問題。