為何不可頻繁執行 DBCC SHRINKDATABASE？碎片與效能陷阱

DBCC SHRINKDATABASE 僅將配置頁從檔案末尾移動至前部未配置頁，**不執行索引重建/整理**，導致：

三大負面影響

1. 增加索引碎片：頁面移動打亂邏輯順序，邏輯掃描需更多頁面跳躍。
2. 降低查詢效能：碎片增加 → 讀取頁面變多 → IO 增加、快取效率下降。
3. 阻塞與記錄檔暴增：收縮過程產生大量記錄、持有鎖，影響並發。

常見誤區

• 「收縮後資料庫變快」 → **錯誤**，實際變慢。
• 「定期收縮維護資料庫」 → **錯誤**，應定期 **重建/重組索引** 維護碎片。
• 「收縮釋放空間給 OS」 → 僅 TRUNCATEONLY 釋放檔案末尾未配置空間，**不移動頁面**，相對安全。

何時適合使用

• **大量刪除/截斷資料表** 後，產生大量未使用空間，一次性收縮釋放磁碟空間。
• 資料庫檔案錯誤設定過大 (如初始 500GB 實際用 50GB)，需歸還儲存配額。
• **搭配索引重建**：收縮後立即執行 ALTER INDEX ... REBUILD 消除碎片。

最佳實務

1. **預設關閉 Auto Shrink** (sp_dboption 'autoshrink', 'off')。
2. 監控檔案使用率 (sp_spaceused、sys.master_files)，僅在必要時手動收縮。
3. 收縮使用 DBCC SHRINKFILE (file_id, target_size_MB) 指定目標大小，避免過度收縮。
4. 收縮後**必須重建相關索引**。
5. 現代大容量磁碟環境，**寧可保留空間預留成長**，避免反覆收縮/成長產生碎片與檔案碎片化。