單獨更新所有統計資訊會導致性能不佳嗎？
多年來，我們一直在使用 Ola Hallengren 的維護腳本對 OLTP 數據庫進行索引優化。（我們在 sql server 2008 R2 上） 2 週前，雖然這裡的一位 DBA 創建了一個維護作業來分別更新統計資訊，並且在索引優化作業之前每週執行一次。似乎在創建它之後，我們在少數儲存過程上遇到了性能問題。我對統計維護不太熟悉，所以我想知道，是否真的有必要單獨執行每周作業來更新所有統計資訊？
這裡的 DBA 似乎認為這是必要的，但我覺得我們在維護作業執行後的第二天早上就開始執行糟糕的儲存過程，並且我經常需要每天至少重新編譯相同的儲存過程 1 或 2 次以下幾個天然後問題就停止了。我的理論指向之前發生的統計數據更新，但我無法找到原因。在一定數量的更改之後或在索引重建期間不會更新統計資訊嗎？為什麼單獨重新計算它們會導致問題？
任何人都可以清楚地說明為什麼每次更新統計資訊時相同的儲存過程都會發生這種情況？
這是用於統計作業的命令：
EXECUTE dbo.IndexOptimize @Databases = 'DB_PRO', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y' , @TimeLimit = 3600, @LogToTable = N'Y';然后索引維護作業執行以下內容：
sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d master -Q "EXECUTE [dbo].[IndexOptimize] @Databases = 'DB_PRO', @TimeLimit = 10800, @LogToTable = 'Y'" -b
問題：我對統計維護不太熟悉，所以我想知道，是否真的需要單獨執行一個每周作業來更新所有統計資訊？
是的，如果你有大表，你需要維護你的統計數據。在此處閱讀自動更新統計資訊的工作原理：
自動更新統計選項統計在查詢編譯之前或執行記憶體查詢計劃之前檢查。在以下情況下，統計數據被視為過時：
空表發生數據更改。在創建統計資訊時，表中的行數為 500 或更少，並且此後統計資訊對象的前導列的列修改計數器已更改超過 500。
統計時該表有500多行，統計對象的前導列的列修改計數器變化超過統計時表中行數的500+20%。
TempDB 中少於 6 行的表至少有 6 行修改。
問題：在一定數量的更改之後或在索引重建期間是否不會更新統計資訊？
重建索引，例如使用 ALTER INDEX … REBUILD 也將更新索引統計資訊，相當於使用 WITH FULLSCAN，除非表已分區，在這種情況下，統計資訊僅被抽樣*（適用於 SQL Server 2012 及更高版本）。重建索引不會更新列統計資訊。
重組索引，對於
> > 使用 ALTER INDEX … REORGANIZE 的範例不會更新任何統計資訊。 > > >
問題：為什麼單獨重新計算它們會導致問題？
可能是因為您的採樣率太低並且統計數據不准確。使用 FULLSCAN 看看是否有幫助。也可能是基數估計誤解了統計資訊（可能發生在 SQL Server 2014 中），如果是這種情況，請嘗試跟踪標誌 9481 以禁用 SQL Server 2014 中的基數估計器。
Ola Hallengrens 腳本的 StatisticsSample 參數為您提供：
以百分比表示更新統計資訊時收集了多少表。值 100 相當於完全掃描。如果未指定任何值，則 SQL Server 會自動計算所需的樣本。