非常大的表的自定義索引維護百分比
我正在使用 Microsoft SQL Server 2016 (SP2-CU12) (KB4536648) - 13.0.5698.0 (X64) Feb 15 2020 01:47:30 版權所有 (c) Microsoft Corporation Standard Edition (64-bit) on Windows Server 2012 R2 Standard 6.3（建構 9600：）
我在一個 2.5 TB 的數據庫上有一些非常大的表（這些表本身可以超過 700GB）。
我一直在使用一些腳本進行索引維護。現在我正在做：
- 如果碎片 > 10% 則重組
- 如果碎片> 50％，則重建。
它在大多數情況下都可以正常工作，但對於我的 700gb 或更大的表，我認為 10% 將是一個很難達到的百分比。我想知道我是否應該降低那些大桌子的百分比，或者將它留在那個門檻值是否可以。
我必須補充一點，我的伺服器有 SSD 驅動程序，但只有 128 GB 的 RAM，因為它是標準版。因此，在大型查詢（如報告）的情況下，表不可能適合 RAM，它必須掃描/查找索引。
我不想因為碎片而遇到 665 錯誤文件系統限制。 https://docs.microsoft.com/en-ie/troubleshoot/sql/admin/1450-and-665-errors-running-dbcc （我開始向數據庫添加文件組以避免該錯誤，因為我’ m 偶爾在屬於主文件組的那些大表上使用它。）
那麼我應該對非常大的表進行索引維護的自定義百分比嗎？還是應該沒問題？
這實際上取決於您的表的事務性。如果它們經常被更新和插入，你肯定會達到 10%。如果您沒有達到 10%，那麼降低到 5% 可能甚至不值得，因為這意味著您的表已經相當完好。
我親自在只有 16 GB RAM 的伺服器上開發了一個與您的範例非常相似的數據庫，也是 SQL Server 2016 標準。我們的數據庫是相當事務性的（每隔幾分鐘添加大約 1,000 條新記錄），我們每晚都達到 10% 的重組門檻值。因為操作非常繁重並且需要一段時間，我實際上做了相反的事情，並將我們更大的表索引的重組碎片門檻值提高到 20%。事實證明，這對我們的業務來說要好得多，因為性能差異可以忽略不計，並且通常允許較大的表在周末之前不進行重組。
擔心索引重組，甚至重建，是需要優化的事情的低端。甚至布倫特奧扎爾也說不用擔心。:)