不斷變化的數據庫增長率是否會強制制定新的執行計劃？
多年來，一直有一個長期執行的 SQL 代理作業需要將近兩個小時才能完成。大約兩週前，出於一個小小的心血來潮，決定更改相關數據庫的增長率。從那時起，這項工作在不到 30 分鐘的時間內就完成了。更改日誌上的增長率會強制生成新的執行計劃。我只是好奇 SQL Server 內部發生了什麼會導致更快的執行時間。
謝謝
我只是好奇 SQL Server 內部發生了什麼會導致更快的執行時間。
當查詢正在執行並且事務日誌文件需要增長時，會發生很多事情，這將不可避免地減慢查詢的總執行時間。
這些事情的非詳盡清單包括：
- 查詢進入等待狀態，
- SQL Server 可能必須等待其他並發查詢完成才能獲得對事務日誌文件的獨占訪問權限，
- SQL Server 呼叫 Windows 文件 API 來增加日誌文件（這取決於驅動程序、Windows 任務調度、磁碟速度等），
- 日誌文件必須“清零”，
- 查詢必須重新啟動並從中斷處恢復處理。
如果此作業確實生成了大量事務日誌（即，它確實插入、更新和刪除），則可能導致日誌增長。如果您將日誌文件的“文件增長”設置增加到更高的值，那麼這個大文件增長操作將不那麼頻繁地發生，並且整個作業將執行得更快（正如您所觀察到的）。
以上所有內容對於數據文件的增長也基本正確，只是數據文件不一定需要清零（如果您啟用了“即時文件初始化”（IFI））。
數據和日誌文件增長設置的預設值非常低，尤其是在舊版本的 SQL Server 上。 一項建議是將它們分別設置為 256 MB 和 128 MB。無論增長設置如何，您都應該盡可能避免這些文件增長事件，尤其是在時間敏感的操作期間。
對於事務日誌的增長，這可能意味著一次做小批量的工作，或者做更頻繁的日誌備份等。
對於數據文件，這可能意味著在維護視窗期間啟用 IFI 和手動增長數據文件，此時您的監控會發出文件幾乎已滿的警報。
我希望從我的回答中可以清楚地看出，執行計劃更改似乎不太可能導致您看到的性能差異。但是要回答標題中的問題，我才意識到我忘了這樣做：
不斷變化的數據庫增長率是否會強制制定新的執行計劃？
我實際上並不確定更改數據文件增長設置是否會使計劃記憶體失效，但我認為不會。
可能，但由於參數嗅探或其他一些表重建或只是統計更新而導致執行計劃更改 - 似乎更有可能從這些來源獲得巨大的性能提升，而不僅僅是自動增長設置本身。
由於增長設置更改而產生的新執行計劃？間接地，它可能會發生。
增長設置本身可能會產生影響，因此，如果增長設置導致大量非常小的增長並且在整個查詢過程中一直停止查詢。它看起來像一個非常慢的文件系統和一個非常小的自動增長設置。
僅僅通過將設置更改為更高的值來加快查詢速度似乎是不尋常的 - 您能確定在此期間沒有更改其他設置嗎？
要定期重複，查詢還必須在下次作業必須再次執行時在文件中找到幾乎為零的淨空（autoshrink 已打開？），或者數據庫正在穩定增長。
一般來說，增長率不應該是一個因素，除非它總是被觸發，所以我會查看每次執行之前可用的數量、期間使用的內容、是否觸發了增長以及是否設置了自動收縮。
Autoshrink 確實會打亂頁面，因此某些表可能會亂序並且可能會影響性能。但不確定它會改變執行計劃。