索引未重新組織

我正在使用 Ola 的 INDEX 維護解決方案。執行作業後很少有索引沒有重新組織。下面是我的程式碼

   EXECUTE 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 = 30,
  @UpdateStatistics = 'ALL',
  @OnlyModifiedStatistics = 'Y',
  @LogToTable = 'Y',
  @PageCountLevel = 0

即使在執行索引優化作業後，很少有碎片級別為 27% 的索引仍然沒有重新組織。

我已經解決了常見問題，它建議 pagecountlevel 在我的情況下已經是 0。

它也有 index_id =1 而不是 0。

我的猜測是這些索引非常小。

亞倫伯特蘭在這裡評論

Ola 的解決方案設置為忽略少於 1000 頁的索引（請參閱@PageCountLevel 參數）。您可以覆蓋它，以便它關心少於 1000 頁的索引，但為什麼呢？恕我直言，浪費精力。

我不會再擔心像這樣的小表了——讓 Ola 的解決方案來完成它的工作，而當你可以證明它確實對特定索引造成了明顯的性能問題時，我會擔心碎片。“碎片化程度高”本身不是問題。

此外，Thomas Stringer在這裡評論

如果索引非常小（我相信少於 8 頁），它將使用混合範圍。因此，它看起來好像仍然存在碎片，因為住房範圍將包含來自多個索引的頁面。

正因為如此，以及在碎片通常可以忽略不計的如此小的索引中，您實際上應該只重建具有特定頁面門檻值的索引。最好的做法是重建至少1000 頁的碎片索引。

要獲得與 Ola 腳本匹配的碎片級別，您需要使用

sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, 'DETAILED') 

並過濾index_level=0

我發現在被證明會導致災難性問題之前，應該忽略無法解釋的碎片化的普遍態度。它解釋了我們在應用程序團隊中的一些經驗。

引用自：https://dba.stackexchange.com/questions/208624