關(guān)于SQL Server壓縮的故事，最早是從SQL Server 2005開始的，在企業(yè)版和開發(fā)版中增加了一種叫做vardecimal的新存儲(chǔ)格式，這個(gè)表級(jí)的選項(xiàng)會(huì)影響到decimal和numeric字段。當(dāng)對(duì)值的精度要求低于字段可用精度，如在一個(gè)decimal(18,9)類型的字段中存儲(chǔ)1.5這個(gè)數(shù)值時(shí)，存儲(chǔ)上就需要有相應(yīng)的壓縮。從效果上來看，它就是一個(gè)varchar類型的數(shù)字型版本。

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

　　無論從哪方面來看，SQL Server 2008的數(shù)據(jù)壓縮都與現(xiàn)在有著巨大的差異(盡管它依然支持或者說包括vardecimal類型)——引起這種差異的真相是，如果你對(duì)一個(gè)給定的table/index啟用壓縮功能，那么底層的row/page格式將不再相同——是的，就是這樣，你聽得沒錯(cuò)——如果你使用壓縮(ROW或者PAGE)，那么SQL 2008的row/page格式將不同于現(xiàn)有的格式(如果你只是在table/index上使用壓縮的話)。因此，在SQL 2008中，有兩種，沒錯(cuò)，是兩種可選row/page數(shù)據(jù)格式。你現(xiàn)在可能會(huì)想知道“那么，如果row/page格式改變了，那你們究竟是如何在這么短的時(shí)間內(nèi)，依然有足夠的時(shí)間去重新生成SQL Server所有需要識(shí)別這些格式的組件的呢?”答案就是我們不需要那樣做——因?yàn)镾torage Engine是SQL 2008中唯一一個(gè)需要知道新的row/page格式的組件。

　　行級(jí)壓縮將大幅減少元數(shù)據(jù)所需的變量長度，較以前每個(gè)字段需要花費(fèi)2個(gè)字節(jié)來存儲(chǔ)，現(xiàn)在只要僅僅3個(gè)位。字段本身現(xiàn)在也變得更小，在整型字段中存儲(chǔ)像1這樣的數(shù)值，只需要一個(gè)字節(jié)，而大數(shù)值則最多只需要4個(gè)字節(jié)。

　　行級(jí)壓縮則允許在行間共享共有數(shù)據(jù)。Chad首先談到的兩種技術(shù)就是列前綴和頁字典：

　　假設(shè)你在一頁的數(shù)據(jù)行中有一列數(shù)據(jù)有這些值：‘Chad’、‘Chadwick’、‘Chadly’、‘Chad’、‘Chadster’、‘Chadwick’和‘Chadly’(故意重復(fù)的數(shù)值)——正如你所見，有相當(dāng)多的冗余‘前綴’數(shù)據(jù)在這一頁的同一列的不同行中，是吧?因此，你最終可能會(huì)想到這樣的一個(gè)場(chǎng)景：將列的前綴‘Chad’存儲(chǔ)在CI結(jié)構(gòu)中，每一個(gè)列的最后都指向這個(gè)前綴值，最后出現(xiàn)在磁盤上的值會(huì)像這樣：‘’，‘1wick’，‘1ly’，‘1ster’，‘1wick’和‘1ly’。

　　所以，對(duì)于上述例子中的含有Chad的同列數(shù)值，在經(jīng)過對(duì)“列前綴”值進(jìn)行計(jì)算和存儲(chǔ)后，你可能得到一個(gè)會(huì)含有如‘1ly’和‘1wick’這些值的頁字典，而真正行內(nèi)數(shù)值則極有可能看上去像這樣：‘’、‘2’、‘3’、‘’、‘1ster’、‘3’和&lsq

　　每一個(gè)頁都是單獨(dú)壓縮的，前綴和字典也存儲(chǔ)在頁內(nèi)。由于頁是存儲(chǔ)分配的原子單位，將半頁壓縮到四分之一頁是沒有任何意義的，所以，只有在頁的內(nèi)容快滿的時(shí)候才會(huì)開始?jí)嚎s處理。

　　在使用行和頁壓縮時(shí)還有一個(gè)性能權(quán)衡問題，因?yàn)?u>CPU使用率會(huì)上升，但I(xiàn)/O使用率和內(nèi)存占用會(huì)下降。

　　Backup Compression是2008的另一個(gè)特性，它是通過普通的文件系統(tǒng)型壓縮技術(shù)實(shí)現(xiàn)的，對(duì)于給定的數(shù)據(jù)庫，只有啟用或者禁用，沒有其它可調(diào)節(jié)選項(xiàng)。