日誌文件收縮對於 SQL 的性能來說是好是壞？

我正在使用 SQL Server 2008 R2 數據庫，在我們的 SQL Server 實例上，我們有 70 多個數據庫。在一些數據庫中，我可以看到事務日誌文件大小超過 10 GB。我每天使用以下腳本縮小 Tlog 文件大小：

USE ABC;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE ABC
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (ABC_log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE ABC
SET RECOVERY FULL;
GO

有沒有推薦的方法來縮小事務日誌文件的大小？

每天收縮日誌文件，就像你對發布的查詢所做的那樣，這是非常糟糕的，你不應該這樣做。主要原因是，在您縮小文件後，當新事務到來時它會再次增長，並且由於日誌文件不存在INSTANT FILE INITIALIZATION，它僅適用於數據文件，當日誌文件增長時，數據庫引擎實際上必須歸零空間來寫入資訊，因此必須用零值（0×0）覆蓋它而不是覆蓋空閒空間，然後才能寫入資訊。此過程需要時間，因此會延遲查詢處理

這個連結已經做了很好的解釋

請注意，即時文件初始化在某種程度上適用於 Tempdb 日誌文件，即使這是正確的，您也不應該每天收縮 tempdb 日誌文件。

一個更簡單的想法，如果在寫入日誌資訊並且日誌會增長時空間最終必須增長，為什麼要縮小。這是一種不好的做法，網際網路上到處都是建議不要縮小數據文件，但縮小日誌文件同樣糟糕

編輯：不用說（正如已經指出的），您通過將恢復模式更改為簡單來破壞日誌鏈。你失去了及時恢復的時間點。如果不需要時間點恢復，則保留數據庫的簡單恢復模型，如果某些東西沒有保存日誌並且在事務中需要它，則數據庫引擎將處理日誌截斷。

… 以一天為周期 …

ALTER DATABASE ABC SET RECOVERY SIMPLE;

是的，這是最糟糕的做法。如果您每天都斷開備份鏈，那有什麼意義呢？

現在回答您的問題：縮小日誌會影響性能嗎？

是的。間接地，因為您縮小到一個太小的文件，您正在極大地影響性能，因為日誌需要恢復到其操作大小。在您的“維護”執行後，您的客戶會經歷痛苦的隨機延遲，因為數據庫被凍結以增長並零初始化日誌文件（日誌沒有即時文件增長！）。

**停下來。**保持備份鏈完好無損。確定每個日誌文件的操作大小，對於每個數據庫，在一次操作中將日誌增加到該大小，保持不變。監控日誌增長事件，確定原因並採取適當的措施。

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