Ola Hallengren 在 SAN 儲存上執行的 sql server 上的 SQL Server 索引和統計維護腳本有什麼用途嗎？
我已經配置了 Ola Hallengren 的備份和完整性檢查腳本。
但是，我需要建議是否需要設置 SQL Server 索引和統計維護腳本，因為我的 SQL 伺服器在 SAN 基礎架構上執行，並且我已經閱讀到將填充因子設置為小於 100% 沒有任何好處，或者當數據文件位於 SAN 儲存上時執行索引重組或索引重建。任何建議將被認真考慮。
統計維護是由 SQL 伺服器自動完成的，所以我看不出配置 Ola 的腳本進行統計維護有什麼好處。
注意，SAN儲存意味著涉及多個磁碟，而數據（無論表是否有索引
$$ heap $$或聚集索引或非聚集索引）分散在多個磁碟上。
的確，索引碎片在過去幾乎是一回事，如果您的數據庫架構正確，那麼如今索引維護幾乎沒有意義，尤其是在使用現代硬體的情況下。我看到索引維護需要的一個例子是在第三方應用程序的數據庫上，他們不相信聚集索引，所以他們所有的表都是堆，經常會出現超過 90% 的碎片並且性能很差。但這就是為什麼我在第一句話中添加免責聲明“如果您的數據庫架構正確”。（請注意，當時這可能是在機械儲存上，這可能會更加暴露完全碎片堆的問題。）
統計維護是一個不同的目標，今天仍然相關。當 SQL 引擎選擇執行計劃來處理您的查詢時，擁有最新的統計資訊有助於更好地估計基數。由於執行計劃中做出了許多不同的不正確決策，糟糕的基數估計（通常當它們偏離一個數量級或更多時）可能會導致性能非常差（無論您的伺服器使用哪種硬體）。
例如，當引擎認為給定查詢將返回的行數被低估時，它可能會低估處理查詢所需的記憶體量，這將使執行計劃缺乏足夠的資源來執行查詢。跑。相反，高估可能會導致向查詢的執行計劃過度配置資源，這也需要時間來分配，然後從伺服器的其餘部分佔用這些資源。如果我沒記錯的話，單個查詢最多可以佔用實例分配的記憶體的 25%。
基數估計不佳可能導致的另一種性能瓶頸是在所選執行計劃中使用了不正確的操作，尤其是在將數據連接在一起時。例如，低估可能會導致選擇 Nested Loops Join 運算符，因為它通常對較小的數據集性能更高，但如果有基數估計，Hash 或 Merge Join 運算符在這種情況下實際上會更高效是準確的。
統計數據並不是最終保證始終具有良好的基數估計的全部，但它是可以幫助（或在表的統計數據過時時損害）這些估計的一個因素。以相對於數據量和這些表更改頻率而言有意義的頻率更新統計資訊是關鍵。更新統計數據不是阻塞操作，但它可以利用相當數量的伺服器資源來執行此操作。
關於 Ola Hallengren 的腳本，我不是它們的專家，因為我個人還沒有使用它們（還），但我的理解是它們提供了更好的粒度和可配置性，以便更適合您的案例安排維護。它們還應該比使用開箱即用的維護計劃安排維護更可靠。由於這些原因，我相信它們是更受歡迎的維護選擇。
Ola 的安裝腳本創建的“索引優化”作業側重於碎片整理，而不是統計更新。它會做：
- 如果碎片級別低於 5%，則無
- REORG 如果它在 5% 和 30% 之間
- 如果超過 30%，則重建
您會通過重建獲得新的統計資訊，但不會通過重組獲得。請注意，您可以擁有經過大量修改的索引，而這些索引不會被碎片化，因此不會導致重建發生，從而使您獲得過時的統計資訊。
除了 Ola 的安裝腳本創建的作業之外，我建議您再創建一項作業，並且該作業側重於更新統計資訊。它可能如下所示：
EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @LogToTable = 'Y'