影響讀取的因素

堆表的結(jié)構(gòu)特征會對數(shù)據(jù)讀取效率產(chǎn)生很大的影響。前面在介紹堆表結(jié)構(gòu)和聚簇因子時，已經(jīng)詳細(xì)說明了其中的一部分影響因素。接下來，我們還會說明需要了解和注意的其他幾個影響因素。

大范圍數(shù)據(jù)讀取的處理方案。

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

大范圍數(shù)據(jù)讀取的處理方案（1）

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

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

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

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

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

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

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

依據(jù)表中所要存儲數(shù)據(jù)量多少的不同，將表分為小型表、中型表、大型表。在這三種類型中，都會有一些對決定表結(jié)構(gòu)產(chǎn)生一定影響的因素，在這里將予以詳細(xì)說明。

小型表

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

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

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

中型表

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

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

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

大范圍數(shù)據(jù)讀取的處理方案（2）

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

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

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

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

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

需要再次強(qiáng)調(diào)的是，盡管為了提高聚簇因子而選擇使用了特定的存儲結(jié)構(gòu)，但時刻都不能忘記表的結(jié)構(gòu)依然是堆表。這類似于我們?yōu)榱颂岣咚俣榷藿烁咚俟罚且话愕膰酪廊徊粫徊鸪?/p>

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

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

大型表

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

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

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

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

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

如果急速增加的數(shù)據(jù)對管理造成了很大的負(fù)擔(dān)，則應(yīng)當(dāng)當(dāng)機(jī)立斷為其創(chuàng)建分區(qū)。關(guān)于如何更好地使用分區(qū)的相關(guān)內(nèi)容將在后面予以詳細(xì)說明。由于經(jīng)常需要對這種類型的表執(zhí)行大范圍數(shù)據(jù)掃描，所以如果再掃描了大量本不應(yīng)該掃描的數(shù)據(jù)，則會導(dǎo)致非常嚴(yán)重的后果。

我們?yōu)槿绾沃粚λ枰臄?shù)據(jù)進(jìn)行讀取的問題提供了多種有效的解決方案。其中構(gòu)建有效的索引和確保最優(yōu)化的SQL執(zhí)行計劃是其中最為重要的兩個方法。除了這些解決方案之外，我們優(yōu)先應(yīng)該解決的問題就是，如何決定只能按照一種順序存儲數(shù)據(jù)的表結(jié)構(gòu)。

不論是調(diào)整索引結(jié)構(gòu)、修改SQL語句，還是改變執(zhí)行計劃，相對而言都比較容易，但改變表的結(jié)構(gòu)卻不是一件容易的事情。

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