資料列壓縮實作
適用於：
SQL Server Azure SQL 資料庫 Azure SQL 受控執行個體
本文摘要說明 Microsoft SQL Server 資料庫引擎如何實作資料列壓縮。 這個摘要提供協助您計畫資料所需之儲存空間的基本資訊。
啟用壓縮僅會變更與資料類型 (但不與其語法或語意) 相關聯之資料的實體儲存格式。 當啟用一個或多個資料表的壓縮時，不需要變更應用程式。 新的記錄儲存格式具有下列的主要變更：
降低與記錄相關聯的中繼資料負擔。 此中繼資料是有關資料行、其長度和位移的資訊。 在某些情況下，中繼資料負擔可能會比舊的儲存格式還大。
針對數值類型 (例如 integer、 decimal和 float) 以及依據數值的類型 (例如 datetime 和 money) 使用可變長度儲存格式。
使用可變長度格式 (不儲存空白字元) 而儲存固定字元字串。
注意
所有資料類型的 NULL 和 0 值都經過最佳化而不使用任何位元組。
資料列壓縮如何影響儲存
下表描述資料列壓縮如何影響 SQL Server 和 Azure SQL Database 中的現有型別。 此表格不包含可藉由使用頁面壓縮而達成的節省量。
| 資料類型 | 儲存是否受到影響？ | 描述 |
|---|---|---|
| tinyint | 否 | 所需的最小儲存區是 1 個位元組。 |
| smallint | Yes | 如果 1 個位元組能容納此值，只會使用 1 個位元組。 |
| int | 是 | 僅使用所需的位元組。 例如，如果值可以儲存在 1 個位元組內，則儲存只會使用 1 個位元組。 |
| bigint | 是 | 僅使用所需的位元組。 例如，如果值可以儲存在 1 個位元組內，則儲存只會使用 1 個位元組。 |
| decimal | 是 | 無論指定的精確度為何，只使用需要的位元組。 例如，如果值可以儲存在 3 個位元組內，則儲存只會使用 3 個位元組。 此儲存磁碟使用量與 vardecimal 儲存格式完全相同。 |
| numeric | 是 | 無論指定的精確度為何，只使用需要的位元組。 例如，如果值可以儲存在 3 個位元組內，則儲存只會使用 3 個位元組。 此儲存磁碟使用量與 vardecimal 儲存格式完全相同。 |
| bit | 是 | 中繼資料負荷將此設為 4 個位元。 |
| smallmoney | 是 | 藉由使用 4 位元組整數來使用整數資料表示。 貨幣值會乘以 10000，再移除小數點之後的任何數字以儲存產生的整數值。 此類型的儲存最佳化與整數類型類似。 |
| money | 是 | 藉由使用 8 位元組整數來使用整數資料表示。 貨幣值會乘以 10000，再移除小數點之後的任何數字以儲存產生的整數值。 此類型的範圍比 smallmoney大。 此類型的儲存最佳化與整數類型類似。 |
| float | Yes | 將不會儲存最小顯著性位元組為零的項目。 float 壓縮主要適用於尾數中的非小數值。 |
| real | Yes | 將不會儲存最小顯著性位元組為零的項目。 real 壓縮主要適用於尾數中的非小數值。 |
| smalldatetime | No | 透過使用兩個 2 位元組整數來使用整數資料表示法，並且它為 1900-01-01 之後的天數。 smalldatetime 的日期部分沒有資料列壓縮優勢。時間是午夜之後的分鐘數。 稍微超過 4AM 的時間值會開始使用第二個位元組。 如果 smalldatetime 只會用來表示日期 (常見的情況)，則時間為 0.0。 壓縮會針對資料列壓縮以最大顯著性位元組格式儲存時間而節省 2 個位元組。 |
| datetime | 是 | 藉由使用兩個 4 位元組整數來使用整數資料表示。 整數值代表天數，基準日期是 1900-01-01。 第一個 2 位元組最多可代表到 2079 年。 在該時間點之前，此處的壓縮一定可以節省 2 個位元組。 每個整數值都代表 3.33 毫秒。 壓縮在第一個五分鐘內就會用盡第一個 2 個位元組，而需要在 4PM 之後使用第四個位元組。 因此，在 4PM 之後僅能節省 1 個位元組。 當 datetime 像任何其他整數一樣進行壓縮時，壓縮可以在日期中節省 2 個位元組。 |
| date | 否 | 藉由使用 3 個位元組來使用整數資料表示法。 這代表從 0001-01-01 日開始的日期。 對於現代的日期而言，資料列壓縮會使用所有 3 個位元組。 如此不會達成任何節省量。 |
| time | No | 採用 3 - 6 個位元組以使用整數資料表示法。 有各種從 0 到 9 開始的精確度，佔用 3 到 6 個位元組。 壓縮空間的用法如下所示： Precision = 0。 位元組 = 3. 每個整數值都代表一秒。 壓縮可藉由使用 2 個位元組而最多代表到 6PM 的時間，因而可能節省 1 個位元組。 Precision = 1。 位元組 = 3. 每個整數值都代表 1/10 秒。 壓縮在 2AM 之前會使用第三個位元組。 產生的節省量很少。 Precision = 2。 位元組 = 3. 與前例類似，不太可能達到節省量。 Precision = 3。 位元組 = 4. 因為在 5AM 之前就會使用了第一個 3 位元組，所以此選項節省的量很少。 Precision = 4。 位元組 = 4. 在第一個 27 秒內就會使用第一個 3 位元組。 不預期有任何節省量。 Precision = 5，Bytes = 5 在中午 12 點之後會使用第五個位元組。 Precision = 6 和 7，Bytes = 5。 不會達到任何節省量。 Precision = 8，Bytes = 6 在凌晨 3 點之後會使用第六個位元組。 資料列壓縮的儲存沒有變更。 整體而言，無法預期從壓縮 time 資料類型達到很大的節省量。 |
| datetime2 | Yes | 採用 6 - 9 個位元組以使用整數資料表示法。 第一個 4 位元組代表日期。 時間所使用的位元組取決於指定的時間精確度。 整數值代表自 0001-01-01 日開始天數，上限則是 9999 年 12 月 31 日。 為了代表 2005 年中的日期，壓縮會使用 3 個位元組。因為它針對不同的時間精確度而允許 2 到 4 個位元組，因此不會節省任何時間。 因此，對於一秒鐘的時間有效位數而言，壓縮會為時間使用 2 個位元組，而在 255 秒之後使用第二個位元組。 |
| datetimeoffset | Yes | 類似 datetime2，但此格式 (HH:mm) 的時區有 2 個位元組。與 datetime2類似，壓縮可節省 2 個位元組。 對於時區值， mm 值在多數情況下可能是 0。 因此，壓縮可能可以節省 1 個位元組。資料列壓縮的儲存沒有變更。 |
| char | 是 | 會移除尾端填補字元。 不論使用的定序為何，Microsoft SQL Server 資料庫引擎都會插入相同的填補字元。 |
| varchar | 否 | 沒有影響。 |
| text | 否 | 沒有影響。 |
| nchar | 是 1 | 會移除尾端填補字元。 不論使用的定序為何，Microsoft SQL Server 資料庫引擎都會插入相同的填補字元。 |
| nvarchar | 否 1 | 沒有影響。 |
| ntext | 否 | 沒有影響。 |
| binary | 是 | 會移除尾端的零。 |
| varbinary | 否 | 沒有影響。 |
| image | 否 | 沒有影響。 |
| cursor | 否 | 沒有影響。 |
| timestamp / rowversion | 是 | 藉由 8 個位元組以使用整數資料表示法。 有針對每個資料庫維護時間戳記計數器，且其值從 0 開始。 這可以像任何其他整數值一般進行壓縮。 |
| sql_variant | 否 | 沒有影響。 |
| uniqueidentifier | 否 | 沒有影響。 |
| table | 否 | 沒有影響。 |
| xml | 否 2 | 沒有影響。 |
| 使用者定義型別 | 否 | 這在內部表示為 varbinary。 |
| FILESTREAM | 否 | 這在內部表示為 varbinary。 |
1 Unicode 壓縮支援固定長度的 nchar 和 nvarchar 資料類型。 不過，無法壓縮以非資料列方式儲存或儲存在 nvarchar(max) 資料行中的資料值。 不支援 nvarchar(max) 資料使用 Unicode 壓縮，即使此資料儲存於資料列中。
2 啟用資料壓縮時，不會壓縮非資料列資料。 例如，大於 8060 個位元組的 XML 記錄會使用未壓縮的資料列外頁面。