繁忙的 OLTP 數據庫上的索引維護
我有一個數據庫，其中一直在發生不斷的讀寫。正在使用萬用字元條目進行搜尋。伺服器為 SQL 2016 標準版。
企業沒有預算，也沒有不使用萬用字元搜尋的意圖，也沒有維護視窗。
由於正在進行萬用字元搜尋，因此索引也沒有用，因為它正在執行全表掃描並因此創建鎖定。
我正在使用 Ola Hallengren 腳本進行索引，但索引維護需要 10-12 小時才能完成 300gb 數據庫，因為它 24/7 忙碌。下面是腳本
執行 dbo.IndexOptimize @Databases = ‘user_databases’，@FragmentationLow = NULL，@FragmentationMedium = ‘INDEX_REORGANIZE，INDEX_REBUILD_ONLINE，INDEX_REBUILD_OFFLINE’，@FragmentationHigh = ‘INDEX_REBUILD_ONLINE，INDEX_REBUILD_OFFLINE’，@FragmentationLevel1 = 5，@FragmentationLevel2 =‘30Level全部’，@OnlyModifiedStatistics = ‘Y’
這已經成為一個令人沮喪的問題，我即將退出。請告訴我在這裡有什麼選擇。
不做索引碎片整理是一種選擇。您是否首先衡量了碎片整理的改進？HQISILON 沒跟我說什麼，你的磁碟子系統是一方面。還有查詢負載、執行計劃等。最好是有一些負載來衡量你實際獲得的東西。
一項並行工作應該是調查您是否有對您沒有幫助的索引。Sys.dm_db_index_usage_stats 在這裡很有用。
如果阻塞是您的問題，那麼考慮進行重組而不是重建。即，將參數更改為proc，因為如果> 30％，您現在會重建。重組比重建（離線模式）更線上。
當 Ola Hallengren 腳本完成時，索引將再次被分割。
- 擴展您的伺服器（增加記憶體和 CPU）
- 用 SDD 代替 HDD
- 從SentryOne、SQL Monitor、SQL Diagnostic Manager、Database Performance Monitoring等購買許可證…並修復那些阻塞和死鎖
索引碎片不是問題，是其他問題的症狀：修復那個，而不是碎片