本文詳細講解了不能頻繁使用DBCC SHRINKDATABASE的原因，這為我們在收縮數據庫找到了可參考的資料。

我們可能為節省空間，或其它原因，經常頻繁地執行DBCC SHRINKDATABASE來收縮數據庫，那么頻繁地執行DBCC SHRINKDATABASE好么？下面就給出相關的解釋。

首先,我們需要了解數據文件并不是所有的空間都會被使用，而是只有部分未使用的空間：包括已刪除的數據、文件自動增長所未使用的空間及其一些不能被使用的碎片空間，這些未使用空間可通過sp_sapceused得到。執行DBCC SHRINKDATABASE后將分配頁從文件末尾移動到文件前部的未分配頁，然后進行壓縮；只有執行了TRUNCATEONLYA，才會將空間釋放給操作系了解DBCC SHRINKDATABASE的收縮原理我們再來看幾個問題：

1.DBCC SHRINKDATABASE 收縮后能起到整理數據庫文件碎片？

不能！DBCC SHRINKDATABASE僅僅是將空間給收縮了，并沒有做善后處理，數據庫文件的碎片只能是更多了。

2．DBCC SHRINKDATABASE收縮后數據庫的速度會快嗎？

不能！DBCC SHRINKDATABASE并沒有在收縮后執行整理索引的步驟，因此，索引的碎片會更多，執行速度應該會慢一些。

3．為什么我每隔幾天就整理索引，但索引的碎片仍然產生的很快？

參考第二條，估計是你在執行索引整理后，又執行了DBCC SHRINKDATABASE。

4.什么時候使用DBCC SHRINKDATABASE？

只有產生許多未使用空間的操作（如截斷表或刪除表操作）后，執行收縮操作最有效，產生碎片較少。

結論：

DBCC SHRINKDATABASE并不是不能使用，而是要慎重使用，尤其不要頻繁使用，因為它會增加數據庫碎片的程度。

注釋：

A: TRUNCATEONLY 將文件末尾的全部可用空間回收給操作系統。但是，TRUNCATEONLY 不在文件內執行任何頁移動。指定的文件只被收縮到最近分配的區。如果隨 TRUNCATEONLY 一起指定，則忽略 target_percent。