據我所知，使用TRUNCATE是一個最小化日誌操作，並不記錄每個記錄的刪除，而DROP日誌刪除操作。我應該在DROP TABLE之前使用TRUNCATE TABLE來避免日誌開銷？
那麼，是不是安全的假設，如果我想擺脫一個比較大的表，我想這是快速發生，以儘可能小的開銷記錄儘可能我應該TRUNCATE TABLE之前，我DROP TABLE？在RECOVERY SIMPLE中這樣做有什麼區別？
我應該注意到，這需要以自動方式（在預先編寫的腳本中）進行，因爲這將部署到客戶端數據庫，其中停機時間和日誌文件增長都可能成爲問題。
雖然TRUNCATE不記錄單個行，但它會記錄頁面/範圍。這就是爲什麼你可以回滾一個截斷（這不是很多人知道）。我的猜測是，如果你只是截斷然後下降，它實際上會比單獨下降慢。如果你在兩者之間做出承諾，也許不是，但是它也將取決於日誌活動，恢復模式，打到檢查點時等。
爲什麼速度在這裏很重要？這不是像用戶使用該表，如果你即將放棄它...
你爲什麼不測試它？除非有人對此進行了廣泛的研究，涵蓋了幾個不同的變量，否則我懷疑你會得到比準教育的猜測更多的東西。
速度是一個因素的原因是因爲這是生產數據庫升級過程的一部分，因此需要將停機時間降至最低。老實說，日誌文件的增長可能更多是一個問題。 –
不知道TRUNCATE是可逆的... –
爲什麼不在升級過程後刪除表？它不像是在升級完成之前需要完成，它只是需要替換爲不同版本的表（我認爲）。我會說將它轉移到不同的模式或重新命名它，然後當用戶不在等待時再放下它。 –
根據我的經驗，truncate比drop更快，特別適用於大型數據集。
我的記憶是，如果恢復設置是「SIMPLE」，那麼關注點就沒有意義了。 –
那麼這是否意味着DROP TABLE在使用SIMPLE恢復模型時被認爲是最低限度記錄的？我還沒有看到任何明確的答案。 –
只要還在同一個事務中，即使在SIMPLE恢復中，也可以還原DROP。 SQL Server中沒有多少真正的「最少記錄」操作。 –