|
|
執(zhí)行SQL查詢時，主要的幾個瓶頸在于：CPU運算速度、內(nèi)存緩存區(qū)大小、磁盤IO速度。而對于大數(shù)據(jù)量數(shù)據(jù)的查詢，其瓶頸則一般集中于磁盤IO，以及內(nèi)存緩存。那么為了提高SQL查詢的效率，一方面我們需要考慮盡量減少查詢設(shè)計的數(shù)據(jù)條目數(shù)——建立索引，設(shè)立分區(qū)；另一方面，我們也可以考慮切實減少數(shù)據(jù)表物理大小，從而減少IO大小。
在SQL Server 2008中，最新提供了一項功能“壓縮（Compression）”，就是定位于減少數(shù)據(jù)表、索引物理大小。
設(shè)置壓縮
在企業(yè)管理器中，在需要壓縮的表或索引上右鍵選擇Storage-》Manage Compression：
這里可以看到幾點：
- 下方列表里列出了該表所有的分區(qū)，也就是可以同一張表的不同分區(qū)應(yīng)用不同的壓縮策略。
- 壓縮方式（Compression Type）分為Row和Page兩種。
行級壓縮（Row）：
一方面減少了動態(tài)長度字段元數(shù)據(jù)的大小（varchar、varbinary等），比如之前存儲字段實際長度需要2bytes，壓縮后只需要3bits。
另一方面也直接減少各字段存儲內(nèi)容的大小，比如存儲數(shù)值1在一個int類型字段中，壓縮后只占用了一個字節(jié)。
頁級壓縮（Page）：能在各行間共享相同的數(shù)據(jù)，這里面包含兩項技術(shù)：列前綴（Column Prefix）、頁字典（Page Dictionary）。
列前綴可以讓擁有同樣前綴的字段值擁有類似外鍵一樣的結(jié)構(gòu)來存儲相同的前綴和各自的其余部分。比如一張存儲了一個網(wǎng)站所有頁面URL的表，URL字段存儲的值分別是‘www.example.com/a.html’，‘www.example.com/b.html’，‘www.example.com/c.html’，‘www.example.com/d.html’。則壓縮后，它們同樣的前綴‘www.example.com/’會被提取出來，而其余部分會被類似如下的形式存儲‘1a.html’，‘1b.html’，‘1c.html’，‘1d.html’。
頁字典則可以將在應(yīng)用列前綴基礎(chǔ)上的其余部分再次聚合存儲，比如同樣是一張存儲了一個網(wǎng)站所有頁面URL的表，假設(shè)有在表里里有多條URL字段的值相同，比如‘1a.html’，‘1b.html’，‘1c.html’，‘1b.html’，‘1a.html’，‘1a.html’，則通過頁字典技術(shù)壓縮后，實際存儲在字段中的值會進一步減少為‘2’，‘3’，‘1c.html’（沒有重復(fù)的字段值不會被壓縮），‘3’，‘2’，‘2’。 - 點擊“Calculate”后，會計算出表當(dāng)前占用的空間大小，以及壓縮需要的空間大小。注意這里與一般預(yù)想的不同，如果要對一張預(yù)存有數(shù)據(jù)但尚未壓縮的表進行壓縮，首先需要的是額外的空間大小。
執(zhí)行壓縮
設(shè)置好之后，就可以選擇是生成腳本還是立即執(zhí)行，一般壓縮的執(zhí)行時間受表原有數(shù)據(jù)多少以及選擇壓縮方式的影響。筆者對一張有上千萬條記錄的表做頁級壓縮，耗時在10分鐘左右。
壓縮完成之后查看數(shù)據(jù)庫大小，會發(fā)現(xiàn)數(shù)據(jù)庫的大小變大了！這也和在設(shè)置階段計算出來的額外空間相關(guān)。但實際上這里大部分空間是預(yù)占的空間，并沒有實際數(shù)據(jù)。如果需要節(jié)省磁盤空間，需要進一步執(zhí)行收縮（Shrink）操作。
與Compression不同，Shrink用來釋放數(shù)據(jù)庫占據(jù)的沒有利用的空間，一般用來對無用的日志文件收縮（如果操作頻繁，日志文件很有可能大于數(shù)據(jù)庫實際數(shù)據(jù)的大小）。這里我們對數(shù)據(jù)庫文件（mdf）做Shrink操作，完成之后再看數(shù)據(jù)庫的大小，果然減少了很多。筆者做壓縮、Shrink之后，一般都能將數(shù)據(jù)庫的大小減為原來的1/3~1/2左右。當(dāng)然，具體壓縮比率取決于壓縮方式、壓縮表的字段特點、壓縮表占整個數(shù)據(jù)庫數(shù)據(jù)的比重等。
注意事項
- 既然對表行了壓縮，那么在執(zhí)行查詢時必然會有解壓縮的過程。而這一過程會占用CPU時間，也就是我們在通過壓縮減少了磁盤占用空間以及IO時間的同時，增大了CPU的消耗。所以在壓縮前需要考慮清楚查詢的瓶頸到底是磁盤IO還是內(nèi)存還是CPU。而且如果表應(yīng)用了壓縮，類似建立索引，對于增刪改等操作也會有一定的影響。所以同樣要考慮應(yīng)用在表上的操作到底以哪種為主。
- 各頁面的壓縮是獨立進行的，頁字典和列前綴也分別存儲于各頁內(nèi)。而且壓縮僅在數(shù)據(jù)頁快滿的時候進行，因為一個頁的大小是固定的，壓縮半頁不會有性能上的提升。
- 數(shù)據(jù)庫備份中也有Compression的選項，但這利用的是系統(tǒng)的文件壓縮技術(shù)，而且只能應(yīng)用于整個數(shù)據(jù)庫上。
- 容易被忽略的是，索引也能被壓縮，而且和表壓縮獨立，同樣也會提升所有應(yīng)用到索引的查詢的性能。
- 在Shrink階段，可能會造成大量的索引碎片，所以可以在Shrink完成之后重建或者重組織索引，但同時，這些操作也會造成數(shù)據(jù)庫的體積變大……也就是，最小的數(shù)據(jù)庫體積和最小碎片比率的索引是魚與熊掌，不可兼得。
it知識庫：【原】SqlServer性能優(yōu)化——Compression，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
