在相對較小的 SQL Azure 數據庫上自動更新統計資訊和重新制定查詢計劃是不好的做法嗎？

我有一個大小約為 500MB 的 SQL Azure 數據庫。每隔 2-3 週，數據庫就會突然開始執行緩慢，並且一些查詢（由 LINQ 生成）會超時。執行時間沒有逐漸增加，只是突然飆升。

修復它的唯一方法是更新統計資訊；我通常同時刪除查詢計劃。然後它恢復正常。

一些索引STATISTICS_NORECOMPUTE=ON在一開始就被錯誤地創建了。由於將它們更改為OFF，因此問題發生的頻率較低。但是，當我查看索引和建表 SQL 時，沒有什麼異常，系統也沒有什麼異常。每天都會添加新行，但沒有異常大或小。我讀到統計資訊只更新了表的 20%+500 已更改，但我有其他類似的數據庫執行沒有問題。

那麼，如果我安排每隔幾天在午夜更新一次統計數據，我是在治療症狀而忽略了難以捉摸的原因嗎？這是不好的做法還是標準的數據庫維護？

SQL Server 優化器使用統計資訊來生成執行計劃。統計數據越準確，它可能生成的計劃就越好。預設情況下，僅當超過 20% 的記錄已更改時，才會自動更新統計資訊。在實踐中意味著什麼？假設您有一個包含 10 個月數據的表，並且剛剛重新計算了統計數據。再次觸發更新統計需要兩個月的時間。如果在此期間有人執行查詢，詢問該 2 個月期間的某些數據，優化器會認為不會有符合條件的記錄，並且可能會生成一個非常糟糕的執行計劃。

過時的統計數據是性能問題的根本原因，而不是症狀，因此應該定期更新。

重組/重建不能替代更新統計工作。Reorganize 根本不會更新統計資訊。重建不會更新所有統計數據。重建期間僅更新索引統計資訊，而不是列統計資訊。

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