SQL Server 資料壓縮完整指南：ROW vs PAGE 壓縮、效能權衡與最佳實務

為什麼需要壓縮？

查詢瓶頸三大金剛：CPU、記憶體、磁碟 I/O。大資料量下，**I/O 與記憶體壓力通常是主因**。壓縮直接減少資料表/索引物理大小 → 降低 I/O 讀取量、提高緩衝區命中率、縮短備份/還原時間。代價：CPU 解壓縮開銷、寫入路徑複雜度上升。

兩種壓縮層級詳細比較

啟用與管理：SSMS 圖形化與 T-SQL

SSMS 操作路徑

物件總管 → 資料表/索引右鍵 → **儲存體** → **管理壓縮** → 選擇分區 → 計算 → 選擇 ROW/PAGE/NONE → 執行/產生腳本。

T-SQL 範例 (建議納入版控)

-- 建表時指定
CREATE TABLE FactSales (
    SaleId BIGINT IDENTITY,
    ProductKey INT,
    SaleDate DATE,
    Amount MONEY
) WITH (DATA_COMPRESSION = PAGE);

-- 現有表/索引啟用/變更 (離線重建，大表需規劃維護窗口)
ALTER TABLE FactSales REBUILD WITH (DATA_COMPRESSION = PAGE);
ALTER INDEX IX_FactSales_Product ON FactSales REBUILD WITH (DATA_COMPRESSION = ROW);

-- 分區表指定特定分區壓縮
ALTER TABLE FactSales REBUILD PARTITION = 5 WITH (DATA_COMPRESSION = PAGE);

壓縮執行過程與空間變化

1. **計算階段**：掃描資料估算壓縮後大小、所需臨時空間。
2. **執行階段**：建立新壓縮結構 (需額外空間約原表 1.2~1.5 倍)、切換中繼資料、刪除舊結構。
3. **完成後**：資料庫檔案大小**不會自動縮小**，空間標記為「可用/未配置」。
4. **必須執行 `DBCC SHRINKFILE` / `SHRINKDATABASE`** 釋放作業系統空間 (會產生大量索引碎片)。

效能權衡與決策矩陣

進階注意事項

• 分區獨立壓縮：同一表不同分區可套用不同策略 (熱區 ROW、冷區 PAGE)。
• 備份壓縮：`BACKUP DATABASE ... WITH COMPRESSION` 使用獨立演算法 (類似 ZIP)，與資料壓縮疊加效果佳。
• 索引碎片：`SHRINK` 後必須 `REBUILD`/`REORGANIZE` 索引，但重建會膨脹檔案。**最小體積與最小碎片不可兼得**，需業務權衡。
• 統計資料：壓縮/重建後自動更新統計資料，大表可加 `WITH STATISTICS_INCREMENTAL = ON` (分區級統計)。
• 版本限制：Enterprise/Developer 版完整支援，Standard 版 SQL 2016 SP1+ 才開放。

總結

資料壓縮是「以 CPU 換 I/O/記憶體」的經典權衡。**ROW 壓縮低風險通用，PAGE 壓縮高收益針對性強**。實施前必測：`sp_estimate_data_compression_savings` 預估壓縮比、CPU 影響、維護窗口。生產部署遵循「冷熱分區差異化、索引同步壓縮、備份疊加壓縮、SHRINK 後重建索引」全鏈路策略，方能最大化收益、最小化風險。