禁用 AUTO_UPDATE_STATISTICS
本週早些時候，我們遇到了一個問題，查詢嚴重倒退，結果，它完全接管了經常執行的 SQL 實例（OLTP 伺服器）。該事件的結果之一是我們考慮禁用 AUTO_UPDATE_STATISTICS，允許夜間維護作業處理統計更新，並在白天保持統計靜態。禁用統計更新的理由是，它將確保我們保留相同的一致計劃。預設情況下，我的偏好是不這樣做，而是更主動地監控記憶體授予和使用的記憶體，使用查詢儲存和/或擴展事件，並在發生重大問題時發出警報。我環顧四周，並沒有真正找到人們在部落格上/發布過關於禁用此選項及其成功的任何實例。
SQL版本：2016標準EE
禁用 AUTO_UPDATE_STATISTICS 是有正當理由的，例如希望更好地控制統計資訊的更新過程。但是，禁用自動更新以防止計劃更改會破壞優化器的目的。
如果您非常了解您的數據，並且您確信無論某些表的增長如何，給定的計劃都會帶來良好的結果，那麼您應該使用查詢儲存或計劃指南來強制執行該計劃（https://docs.microsoft。 com/en-us/sql/relational-databases/performance/plan-guides?view=sql-server-ver15）。然而，在進入這類解決方案之前，您應該嘗試更標準的方法，例如添加索引、重寫查詢、添加提示等。
避免使用“shotgun”方法，例如禁用 auto_update_statistics 或為整個實例設置 MAXDOP =1。相反，您應該辨識正在成為痛點的特定查詢並分析它們的執行。包含的“更新檔”，例如索引創建、提示甚至是針對特定查詢的強制計劃，應始終優先於會全面影響您的工作負載的配置更改。
我希望這有幫助。
按計劃更新統計資訊而不是使用 AUTO_UPDATE_STATISTICS 對於許多數據庫來說效果相當好。但我認為它在這裡反應過度。而是打開查詢儲存並監視錯誤的計劃和其他昂貴的查詢。