SQL Server 2008的新壓縮特性

關於 SQL Server 壓縮的故事，最早是從 SQL Server 2005開始的，在企業版和開發版中增加了一種叫做 vardecimal 的新儲存格式，這個表級的選項會影響到 decimal 和 numeric 欄位。當對值的精度要求低於欄位可用精度，如在一個 decimal（18,9）型別的欄位中儲存1.5這個數值時，儲存上就需要有相應的壓縮。從效果上來看，它就是一個 varchar 型別的數字型版本。

　　SQL Server 2008所包含的已遠不止這些小技巧，Chad Boyd 寫到 ：

　　無論從哪方面來看，SQL Server 2008的資料壓縮都與現在有著巨大的差異（儘管它依然支援或者說包括 vardecimal 型別）——引起這種差異的真像是，如果你對一個給定的 table/index 啟用壓縮功能，那麼底層的 row/page 格式將不再相同——是的，就是這樣，你聽得沒錯——如果你使用壓縮（ROW 或者 PAGE），那麼 SQL 2008的 row/page 格式將不同於現有的格式（如果你只是在 table/index 上使用壓縮的話）。因此，在 SQL 2008中，有兩種，沒錯，是兩種可選 row/page 資料格式。你現在可能會想知道“那麼，如果 row/page 格式改變了，那你們究竟是如何在這麼短的時間內，依然有足夠的時間去重新生成 SQL Server 所有需要識別這些格式的元件的呢？”答案就是我們不需要那樣做——因為 Storage Engine 是 SQL 2008中唯一一個需要知道新的 row/page 格式的元件。

　　行級壓縮將大幅減少後設資料所需的變數長度，較以前每個欄位需要花費2個位元組來儲存，現在只要僅僅3個位。欄位本身現在也變得更小，在整型欄位中儲存像1這樣的數值，只需要一個位元組，而大數值則最多隻需要4個位元組。

　　行級壓縮則允許在行間共享共有資料。Chad 首先談到的兩種技術就是列字首和頁字典：

　　假設你在一頁的資料行中有一列資料有這些值：‘Chad’、‘Chadwick’、‘Chadly’、‘Chad’、‘Chadster’、‘Chadwick’和‘Chadly’（故意重複的數值）——正如你所見，有相當多的冗餘‘字首’資料在這一頁的同一列的不同行中，是吧？因此，你最終可能會想到這樣的一個場景：將列的字首‘Chad’儲存在 CI 結構中，每一個列的最後都指向這個字首值，最後出現在磁碟上的值會像這樣：‘’，‘1wick’，‘1ly’，‘1ster’，‘1wick’和‘1ly’。

　　所以，對於上述例子中的含有 Chad 的同列數值，在經過對“列字首”值進行計算和儲存後，你可能得到一個會含有如‘1ly’和‘1wick’這些值的頁字典，而真正行內數值則極有可能看上去像這樣：‘’、‘2’、‘3’、‘’、‘1ster’、‘3’和‘2’。通過這種方式，我們讓原本需要大約25個位元組來儲存的行資料，減少到只要大約17個位元組來儲存，節省30％以上。

　　每一個頁都是單獨壓縮的，字首和字典也儲存在頁內。由於頁是儲存分配的原子單位，將半頁壓縮到四分之一頁是沒有任何意義的，所以，只有在頁的內容快滿的時候才會開始壓縮處理。

　　在使用行和頁壓縮時還有一個效能權衡問題，因為 CPU 使用率會上升，但 I/O 使用率和記憶體佔用會下降。

　　Backup Compression 是2008的另一個特性，它是通過普通的檔案系統型壓縮技術實現的，對於給定的資料庫，只有啟用或者禁用，沒有其它可調節選項。

　　儘管非企業版伺服器可以恢復帶壓縮的備份，但這所有的壓縮選項極有可能成為企業版專享選項。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-539630/，如需轉載，請註明出處，否則將追究法律責任。