新伺服器上的 Tempdb 日誌增長慢 3 倍，SP 不執行
我們遇到的問題是，我們在新 SQL Server 上的儲存過程比舊伺服器上的執行速度慢很多。我們調查了這個問題，並在我們的臨時數據庫中註意到了以下內容。在新伺服器上增量增長需要 3 倍的時間。我們數據庫的日誌文件也是如此。這是什麼原因造成的？
我們遇到的問題是，我們在新 SQL Server 上的儲存過程比舊伺服器上的執行速度慢很多。
使用Session Wait Stats和Query Store來確定新伺服器上是否有更多等待（如 IO）或查詢計劃是否更糟。
在新伺服器上增量增長需要 3 倍的時間。
使用DISKSPD對兩台伺服器上的 IO 性能進行基準測試。日誌文件增長總是需要將分配的空間歸零。還要預先調整日誌文件的大小並增加自動增長增量。
正如 David Spillett 的評論所指出的那樣，雖然確定為什麼新伺服器上的增長需要更長的時間是一項很大程度上取決於您的環境的任務，但您可能以一種對您的伺服器來說不是最佳的方式調整了 tempdb ，導致頻繁觸發自動增長。
正如 Brent Ozar 在他的備忘單上所說：如何為 Microsoft SQL Server 配置 TempDB：
為 TempDB 配置一個卷/驅動器。將總空間除以 9，這就是您的尺寸。創建 8 個大小相同的數據文件和一個日誌文件，每個文件大小相同。Presto，驅動器已滿，您的 TempDB 已配置為易於執行。
Optimizing tempdb performance in SQL Server文件中也列出了適當調整 tempdb 的大小作為一種良好做法：
通過將文件大小設置為足以容納環境中典型工作負載的值，為所有 tempdb 文件預分配空間。預分配可防止 tempdb 過於頻繁地擴展，從而影響性能。tempdb 數據庫應設置為自動增長，以增加磁碟空間以應對計劃外異常。
最後，如果您的新伺服器具有超過 64 個 CPU，則有關在具有超過 64 個 CPU 的電腦上執行 SQL Server 的最佳實踐的文件說：
不要依賴自動增長來增加事務日誌文件的大小。增加事務日誌必須是一個串列過程。擴展日誌可以防止事務寫入操作繼續進行，直到日誌擴展完成。相反，通過將文件大小設置為足以支持環境中典型工作負載的值，為日誌文件預分配空間。
主要考慮防止事務寫操作這一點，如果沒有執行任何寫操作的SP，它會受到自動增長的影響。
所以，即使這個建議沒有回答你關於增長需要更長時間執行的原因的問題，我認為值得一提。