但是，分布式分區(qū)視圖(dpv)受到很多限制，你可以在sql server的在線幫助文檔中閱讀到。雖然dpv在一些情況下能夠提供性能上的提高，但是這種技術(shù)不能被廣泛的應(yīng)用。已經(jīng)被證明它們不能滿足逐步增長的企業(yè)級應(yīng)用的要求。何況，dpv的實現(xiàn)是一個費力的過程，需要dba進行很多工作。

　　sql server 2005開始支持表分區(qū)，這種技術(shù)允許所有的表分區(qū)都保存在同一臺服務(wù)器上。每一個表分區(qū)都和在某個文件組(filegroup)中的單個文件關(guān)聯(lián)。同樣的一個文件/文件組可以容納多個分區(qū)表。

　　在這種設(shè)計架構(gòu)下，數(shù)據(jù)庫引擎能夠判定查詢過程中應(yīng)該訪問哪個分區(qū)，而不用掃描整個表。如果查詢需要的數(shù)據(jù)行分散在多個分區(qū)中，sql server使用多個處理器對多個分區(qū)進行并行查詢。你可以為在創(chuàng)建表的時候就定義分區(qū)的索引。 對小索引的搜索或者掃描要比掃描整個表或者一張大表上的索引要快很多。因此，當(dāng)對大表進行查詢，表分區(qū)可以產(chǎn)生相當(dāng)大的性能提升。

　　現(xiàn)在讓我們通過一個簡單的例子來了解表分區(qū)是如何發(fā)揮作用的。在這篇文章中，我不想深入到分區(qū)的語法細節(jié)當(dāng)中，這些你可以在sql server的在線幫助文檔中找到。下面的例子基于存儲著一個時間報表系統(tǒng)的數(shù)據(jù)的數(shù)據(jù)倉庫。除了默認的文件組，我另外創(chuàng)建了7個文件組，每一個文件組僅包含一個文件，這個文件將存儲由分區(qū)函數(shù)定義的一部分數(shù)據(jù)。

　　為了測試表分區(qū)的性能提升，我向這個分區(qū)表中插入了一千五百萬行，同時向另外一個具有相同表結(jié)構(gòu)、但是沒有進行分區(qū)的表插入了同樣的數(shù)據(jù)。對分區(qū)表執(zhí)行的insert語句運行的更快一些。甚至在我的內(nèi)存不到1g的筆記本電腦上，對分區(qū)表的insert語句比不分區(qū)的表的insert語句要快上三倍。當(dāng)然，查詢的執(zhí)行時間依據(jù)硬件資源的差異而所有變化，但是你還是能夠在你的環(huán)境中感到不同程度的提升。

　　我將檢查更深入了一步，通過分別檢查同一條返回所有行的、簡單select語句在分區(qū)表和非分區(qū)表上的執(zhí)行計劃，返回的數(shù)據(jù)范圍通過where語句來指定。同一條語句在這兩個不同的表上有不同的執(zhí)行計劃。對于分區(qū)表的查詢顯示出一個嵌套的循環(huán)和索引的掃描。從本質(zhì)上來說，sql server將兩個分區(qū)視為獨立的表，因此使用一個嵌套循環(huán)將它們連接起來。對非分區(qū)的表的同一個查詢則使用索引掃描來返回同樣的列。當(dāng)你使用同樣的分區(qū)策略創(chuàng)建多個表，同時在查詢中連接這些表，那么性能上的提升會更加明顯。

　　你可以使用下面的查詢來了解每一個分區(qū)中的行的個數(shù)：

　　表分區(qū)對交易環(huán)境和數(shù)據(jù)倉庫環(huán)境來說，都是一個重要的特征。數(shù)據(jù)倉庫用戶最主要的抱怨是移動事實表(fact table)會花費太多時間。當(dāng)裝載數(shù)據(jù)到事實表的時候，用戶查詢(立方體處理查詢)的性能會明顯下降，甚至是完全無法成功。因此，裝載大量的數(shù)據(jù)到事實表的時候常常需要停機。如果使用表分區(qū)，就不再出現(xiàn)這樣的情況——確切的講，你一眨眼的工夫就可以移動事實表。為了演示這是如何生效的，我使用上面例子中相同的分區(qū)函數(shù)和表結(jié)構(gòu)來創(chuàng)建一個新的表，這個表叫做fact_time_entry2。表的主鍵從五千萬開始，這樣fact_time_entry2就不會包含表fact_time_entry中已經(jīng)有的數(shù)據(jù)。

　　現(xiàn)在我把2007年的數(shù)據(jù)移動到這張fact_time_entry2中。同時讓我們假設(shè)fact_time_entry表中包含著2007年之前的數(shù)據(jù)。在fact_time_entry2表完成數(shù)據(jù)的轉(zhuǎn)移，我執(zhí)行下面的語句：

　　這條語句將編號為8的分區(qū)，這個分區(qū)恰好包含著2007年的數(shù)據(jù)，從fact_time_entry2移動到了fact_time_entry表中，在我的筆記本電腦上，這個過程只花費了3毫秒。在這短短的3毫秒中，我的事實表就增加了五百萬條記錄!的確，我需要在交換分區(qū)之前，將數(shù)據(jù)移動到中間表，但是我的用戶不需要擔(dān)心——事實表隨時都可以查詢!在這幕后，實際上沒有數(shù)據(jù)移動——只是兩張表的元數(shù)據(jù)發(fā)生了變化。

　　我可以使用類似的查詢刪除事實表中不在需要的數(shù)據(jù)。例如，假設(shè)我們決定我們不再關(guān)心2004年的記錄。下面的語句可以將這些記錄轉(zhuǎn)移到我們創(chuàng)建的工作表中：

　　這樣的語句依舊在毫秒級內(nèi)完成了。現(xiàn)在，我可以刪除fact_time_entry2或者將它移到其他的服務(wù)器上。我的事實表不會包含2004年的任何記錄。這個分區(qū)還是需要在目的表中存在，而且它必須是空的。你不能將分區(qū)轉(zhuǎn)移到一個包含重復(fù)數(shù)據(jù)的表中。源表和目的表的分區(qū)必須一致，同時被轉(zhuǎn)移的數(shù)據(jù)必須在同一個文件組中。即使受到這么多的限制，轉(zhuǎn)換分區(qū)和無需停機就可以移動數(shù)據(jù)表的功能必將讓數(shù)據(jù)倉庫的實現(xiàn)變的前所未有的輕松。