影響讀取的因素

堆表的結構特征會對數據讀取效率產生很大的影響。前面在介紹堆表結構和聚簇因子時，已經詳細說明了其中的一部分影響因素。接下來，我們還會說明需要了解和注意的其他幾個影響因素。

大范圍數據讀取的處理方案。

提高聚簇因子的處理方案及重構表時的注意事項。

大范圍數據讀取的處理方案（1）

在堆表中，由于數據是按照插入順序被存儲在磁盤的任意位置上，所以存儲時所需要付出的代價相對較少。但是在讀取滿足特定查詢條件（SQL語句中WHERE之后的條件）的數據時，所需要付出的代價則相對較大。當然，這并不是我們所能左右的事情。我們知道，當讀取的數據量非常少時，不論怎么讀取都能獲得非常好的讀取效率；但是當讀取的是海量數據時，問題就從根本上發生變化了。

例如，當人體內的病菌數量非常少時，只需要通過打預防針，以增強免疫力，就能夠治愈。但是，當人體內的病菌數量非常多時，以至到了威脅生命的程度，那就不再是僅僅通過注射預防的藥物就能夠治愈的問題了。再比如，假設讀取1行數據需要花費0.01秒，那么讀取10行數據也只不過是花費了0.1秒而已。但是如果需要讀取1億行數據，則所花費的時間為1 000 000秒，即277小時，將近12天。在查詢數據時，等待0.1秒也許根本就覺察不到；但是如果要等待12天，則無論如何都是無法忍受的。

雖然這里舉的這個例子有些極端但卻是事實。在必須要處理海量數據的情況下，所采用的處理方案從根本上就應與面對少量數據時不同。因此，作為用戶，我們首先應當認識到這一問題的嚴重性，絕不可以掉以輕心。很多用戶認為，在處理海量數據時不應當使用堆表，事實并非如此，堆表在管理海量數據方面具有其他類型表無法比擬的優勢。在堆表結構中，由于處理海量數據的各種解決方案（并行處理、分區、各種索引等）都可以使用，所以在現實中有很多用戶都在使用堆表來存儲海量數據。

即便在預測到將要處理的數據量會非常大的情況下，也仍然可以選擇使用堆表來存儲數據，這主要是因為這可以減輕數據插入時的負擔。當然，如果插入數據時的負擔并不是很大，則為了提高數據的讀取效率，我們可以選擇使用其他類型的表來存儲數據。但是，在對數據存儲速度要求非常高的情況下，相信沒有哪個用戶愿意為了給數據尋找一個好的存儲位置而花費時間。

有些用戶可能會把需要存儲的數據暫時存儲在臨時位置上，等到閑暇時再將數據移動到磁盤的合適位置，但是這種方法并不像我們想象的那樣容易。事實上，在大部分的RDBMS中，都是只在內存中對用戶要求的數據進行處理，然后等到閑暇時再將處理結果從內存中移出并存儲在磁盤的合適位置上。我們將此方式稱為延遲寫入（Deffered Write）。

在我們所開發的應用程序中，如果試圖使用延遲寫入的方法來處理數據，則由于每次都要通過編寫代碼來實現，使用起來會比較費勁。綜上所述，在無法避免由于插入數據而造成的很大負擔的情況下，不僅要對堆表予以充分的肯定，而且還要盡最大努力去尋找其他有效解決方案。在本書的后面會不斷涉及此問題的不同解決方案，在此不進行過多說明。

在作者看來，堆表其實是最普遍的數據存儲結構。乍一看，好像堆表只是在存儲海量數據方面比較有效；但事實并非如此，也希望各位讀者不要產生不必要的錯覺。堆表所具有的唯一優點就是在數據插入時不需要采取任何特別的措施，只需順其自然按照數據插入的順序存儲，因此減少了插入大量數據時的代價。僅此而已，再無其他任何優勢可言。

依據表中所要存儲數據量多少的不同，將表分為小型表、中型表、大型表。在這三種類型中，都會有一些對決定表結構產生一定影響的因素，在這里將予以詳細說明。

小型表

首先來分析一下小型表的特征，所謂的小型表就是指表中所存儲的數據量相對較少。這不僅意味著數據插入時的代價相對較小，而且還意味著數據被分散存儲在較少的數據塊上。假設把小型表中數據的存儲區域視為一個個圓，則該圓的半徑也會相對較小。例如小村子里的人們即使居住得比較分散，相對而言他們之間的距離其實也并不怎么遠。然而，表的這些特征會對后來的數據讀取有著非常大的影響。

在關系型數據庫中，不論是何種類型的數據讀取，每次最少都需要讀取一個以上的數據塊。由于小型表數據塊數量相對較少，重復讀取緩存在內存中的概率也相對較大，所以盡管是隨機讀也能獲得非常好的數據讀取效率。

如果小型表是在關鍵訪問路徑（Critical Access Path）上，則即使非常微小的差異也會由于頻繁讀取而被放大得非常明顯。在此情況下，就有必要使用更加有效的方法（例如索引組織表，或者聚簇表）來存儲數據。事實上，由于大部分小型表都不在關鍵訪問路徑上，所以除了特殊情況之外，一般沒有必要采取額外的措施。

中型表

現在讓我們再來思考一下中型表。對中型表進行具體定義是比較困難的，而且也沒有必要必須對其下一個定義。這里所介紹的中型表是指，位于處理代價非常大的大型表與處理代價非常小的小型表之間的所有表。我們知道，在幾乎所有的分類中，位于中間的類型通常都是最一般且所占比例最大的部分。

所謂的中型表不僅意味著數據插入時的負擔不像大型表那樣會對整個系統有著決定性的影響，而且還意味著在各種應用中頻繁被讀取的概率相對來說較大。讓我們從常識的角度來思考一下中型表，反正數據插入時都需要付出一定的代價，還不如采用有利于數據讀取的固定存儲方式來存儲數據。這樣盡管在某種程度上增加了一些數據插入時的代價，但換回的卻是高效率的數據讀取。

雖然這種想法具有一定道理，但由于按照固定存儲方式只能確保一種存儲順序，所以也只是在讀取特定列時能夠獲得較好的效率。對于其他列而言，根本無法改變其值處于分散狀態的事實。這個概念在介紹聚簇因子時，已經進行了詳細說明。

大范圍數據讀取的處理方案（2）

換言之，使用以某個特定順序存儲數據的方法并不能滿足所有的讀取要求。這主要是因為這種存儲方法只能確保在特定的讀取類型中獲得較好的效率。通常情況下，對大部分表的讀取要求并不僅局限于某幾個特定的讀取類型，而是多種多樣的。所以，從理論上來看，根本就不存在一種能夠滿足所有讀取要求的數據存儲方式。

從任意列的角度來看，不論采用何種方式對數據進行存儲，整個表中的數據都將被認為是分散地存儲著的。然而，即使無法通過使用存儲方式來提高讀取效率，我們也不能放棄尋找其他能夠提高隨機讀取效率的解決方案。

如果某個特定的讀取類型不僅具有非常重要的地位，而且值得為確保其讀取效率而采用一些必要措施，則我們應當對其予以高度重視。這就好像侍衛為了確保皇帝的安危而提前做好各種防護措施；又如為了提高首爾至釜山快速列車的速度，直接修建了一條名為京釜線的高速鐵路。

至此我們的結論就比較清晰了：首先，選定最為重要的讀取類型；其次，通過調查分析來決定是否有必要為該讀取類型采取一些特殊的措施。在此情況下，我們還應當集中精力尋找除了此方法之外的其他解決方案，如果能夠找到自然是最理想的；如果費了九牛二虎之力也沒能找到，則只能采用這種方法了。對于世界上的所有問題而言，我們始終追求的最理想解決方案就是以最少的代價換取最大的回報。如果各位讀者對經濟學比較了解的話，則會知道在經濟學中所追求的是以最低的成本支出換取最大的利潤回報。所以我們在解決問題時，也應當追求一下"經濟效益"。

如果決定按照某個（或多個）特定列的順序來存儲數據，則必須為了提高其他列的讀取效率而努力尋找解決方案。由于這里所涉及的解決方案幾乎是本書中所要討論的主要話題，所以在此就不對其進行詳細說明了。

需要再次強調的是，盡管為了提高聚簇因子而選擇使用了特定的存儲結構，但時刻都不能忘記表的結構依然是堆表。這類似于我們為了提高速度而修建了高速公路，但是一般的國道依然不會被拆除。

就像如果由于修建高速公路的支出太大，大到會對財政支出帶來一定的負擔，那就需要我們反復探討一樣，如果數據插入時的代價超出了承受的范圍，則就需要我們對使用特定位置存儲數據的方式予以重新考慮。這里所介紹的原理不僅適用于中型表，也適用于大型表和小型表。但不同的是，對于大型表而言，不僅數據插入的負擔比較大，數據讀取的類型也比較多，所以采用堆表會比較有效。

迄今為止，我們已經從不同的角度對堆表進行了全面分析，從中可以發現堆表就是最一般的數據存儲結構。在大部分情況下，由于數據被分散存儲的順序與我們所要查詢的數據順序之間并沒有任何必然的聯系，所以只能通過大量的數據讀取來查找我們所期望的數據，從而使系統需要付出大量額外的代價。綜上所述，我們無法單一地只通過選擇數據的存儲結構來提高所有數據讀取類型的效率。

大型表

最后讓我們再來考慮一下大型表。對大型表的分類方法有很多，在這里我們將其分為以下三類。

第一類：單純的存儲型表。在這里以管理日志信息的表為例來進行說明，這樣的表既不會被經常使用，也不會有多樣化的讀取要求。只有在特殊的情況下，才有可能要求按照特定的讀取類型讀取數據，或對大量的數據進行掃描，并且日志表還要求具有較快的存儲速度。綜合這些特征和要求，使用堆表來存儲此類數據是最佳的選擇。另外，由于數據增長的速度會比較快，所以最好能夠為其創建分區。

第二類：像顧客表這樣雖然存儲著大量的數據，但主要是以隨機讀取為主，并不存在多樣化的讀取類型的表。這種情況下，堆表仍然是比較適合的選擇。一次性向這樣的表中插入大量數據的情況非常少見，范圍處理（要求處理的數據范圍相對比較大）的情況也不會經常出現。

盡管按照某個列對表進行了分區，但是經常會出現并不是只讀取某個特定分區的情況，而且為了某個特定部分而對其進行單獨操作的機會也并不多，所以即使創建了分區表或聚簇表，也不會獲得太大的效益。

第三類：像銷售表這樣的表不僅數據急速大量增加，而且具有多樣化的數據讀取類型。一般情況下，擁有這種特征的表對系統會產生極大的影響。不論從數據管理的角度還是從數據讀取的角度來看，都具有非常大的負擔。如果我們沒有為這種類型的表制定出合理的解決方案，那么各種問題就會接踵而至。

如果急速增加的數據對管理造成了很大的負擔，則應當當機立斷為其創建分區。關于如何更好地使用分區的相關內容將在后面予以詳細說明。由于經常需要對這種類型的表執行大范圍數據掃描，所以如果再掃描了大量本不應該掃描的數據，則會導致非常嚴重的后果。

我們為如何只對所需要的數據進行讀取的問題提供了多種有效的解決方案。其中構建有效的索引和確保最優化的SQL執行計劃是其中最為重要的兩個方法。除了這些解決方案之外，我們優先應該解決的問題就是，如何決定只能按照一種順序存儲數據的表結構。

不論是調整索引結構、修改SQL語句，還是改變執行計劃，相對而言都比較容易，但改變表的結構卻不是一件容易的事情。

原文鏈接：http://book.51cto.com/art/201010/231701.htm