一、 在數據庫排序查詢優化上的差異。
在講解這個內容之前，為了讀者能夠清楚我講的內容，我要先談一個概念。命中率，它是指從內存中取得數據而不從磁盤中取得數據的比率。我們在前幾篇文章中都提到過，當在數據庫中查詢數據時，數據庫服務器都是先從內存中尋找數據。只有在內存中數據不存在的情況下，才會去讀取數據庫文件的內容。而且，從內存中查詢數據要比在數據庫文件中查詢數據效率高得多。從這方面講，我們若能夠提高這個查詢的命中率，則顯然可以提高數據庫系統的查詢效率。
雖然SQL Server與Oracle在這方面都有所作為，但是，筆者認為，Oracle數據庫在這方面的優勢比較明顯。特別是Oracle數據庫采用了臨時段的管理機制，明顯提高了數據庫查詢的命中率。
那什么叫作數據庫的臨時段呢?假設當我們剛查完員工信息表后，此時，員工信息表的內容就存在數據庫服務器的內存中。此時，我們需要對這個表進行排序查詢，如我們希望查詢出工齡超過兩年的員工，并且按工齡的長短進行排序。此時，Oracle數據庫服務器會設法在內存中排序區對所有行進行排序。而這個排序區的大小則有數據庫的初始化文件init.ora進行確定。當這個排序區不夠大，不能夠容納我們所查詢出來的員工信息記錄數時，數據庫就會在排序操作期間，在數據庫服務器中開辟臨時段。很明顯，在查詢操作過程中，若開辟臨時段的話，會減低數據庫的命中率，降低排序查詢的效率。我們現在希望這個排序能夠在內存中完成，而不需要開辟額外的臨時段，如此的話，就可以消除向臨時段寫數據的開銷，提高排序查詢的效率。所以，當我們數據庫中的數據比較龐大時，我們可以考慮增加這個排序區的長度，以避免臨時段的需要。正是這個臨時段的問題，如我們剛查詢完員工信息表，查詢完成之后，再對該表進行排序查詢，就覺得好像仍然是新的查詢一樣。其實，這個排序查詢的問題，我們可以通過一定的方法對此進行優化，以提高排序查詢的效率。
修改方法：
第一步:先利用查詢語句判斷，是否有臨時段需求的產生。
select * from v$sysstat where name='dtmfg(disk)' or name='dtmfg(memory)';
如我們可以定時利用以上語句，來查詢是否有臨時段需求的產生。這條語句中，dtmfg是具體的數據庫實例名，我們只需要修改這個名字，就可以查詢到我們需要的內容。若在查詢結果中，發現有臨時段需求產生的話，則就需要考慮修改相關的配置文件，以優化排序查詢性能。
第二步：修改參數配置文件。
我們需要修改inint.ora文件，修改里面的SORT-AREA-SIZE的值。不過，修改這個配置文件之后，還必須重新啟動數據庫才會生效。一般情況下，數據庫管理員需要定時查詢這個臨時段需求，然后根據情況，不斷的進行調整，做好數據排序查詢優化功能。
而在微軟的SQL Server數據庫中，筆者沒有發現類似的功能。
二、 利用哈希聯接，提高多表查詢性能。
多表之間的關聯查詢，無論是哪種關聯類型，到數據量比較大時，對于數據庫服務器的查詢性能都是一個非常大的考驗。所以，在實際數據庫設計中，當數據量比較大的時候，需要采用哈希聯接，來提高數據庫多表查詢的效率。一般來說，哈希聯接比其他幾種表之間的連接方式，對于服務器來說開銷要小得多，從而可以提高服務器的查詢效率。
哈希聯接一共有三種聯接方式，分別為內存中的哈希聯結、Gracle哈希聯接與遞歸哈希聯接。
所謂內存的哈希聯接，是指先掃描或計算整個生成輸入，然后在內存中生成哈希表。根據哈希鍵計算出哈希值，然后將每行插入哈希存儲。如果整個生成輸入比可用內存少，則可以將所有行都插入到哈希表中。生成階段之后就是探測階段。一次一行的3對整個探測輸入進行掃描或者計算，并為每個探測行計算哈希健的值，并按一定的規則生成匹配項。
其他兩種哈希聯接也各有各的用途，在這里就不重復描述了。下面，筆者談談在這兩個數據庫中，對于哈希聯接所持的不同態度。
在微軟的SQL Server數據庫中，默認情況下，是采用哈希聯接的。在優化過程中并不能夠確定到底采用上面的那種聯接方式。所以，微軟的數據庫系統默認情況下，實采用內存中的哈希聯接，然后再根據生成輸入的大小逐漸轉換到GRACLE哈希聯接以及遞歸哈希聯接。
但是，若是在數據量不大的情況下，哈希聯接不但不會提高數據庫的查詢效率，反而會有所下降。所以，Oracle數據庫在默認情況下，是沒有啟用哈希聯接的，而是在實際需要時，可添加一些設置使得數據庫在有多大聯接查詢發生時才利用哈希聯結。也就是說，Oracle數據庫可以設置判斷條件，數據庫管理員可以指定，當滿足一定的條件時才調用哈希聯結，利用它來提高多表查詢的效率。
三、 大表查詢優化。
一般來說，在數據庫設計中，數據庫設計人員會利用索引等技術來提高數據庫的查詢效率。但是，索引的作用，也不是無限擴大的，它受到一定的限制。一般來說，他跟數據量是成反比的，當數據量越大時，他的作用就越小。確切的說，剛開始時隨著數據量的增大其對數據庫查詢的優化作用會逐漸增大;但是，當數據數量累積到一定程度時，其效果就會逐漸減小。當數據量達到一定的程度，如一百萬條時，索引的作用就非常微小了。
針對這種大容量記錄的表，若需要查詢，其查詢效率不高。為此，數據庫該采用什么方式來提高這個大表的查詢效率呢?
這兩大數據庫不約而同的采用了哈希族的方式，來提高大表的查詢。
如現在在設計一個圖書館管理系統，這個系統中，讀者的信息有幾百萬、幾千萬條。當讀者的信息存儲在一個普通表中的時候，這些記錄按照存儲到數據庫中的先后順序，物理地保存到分配的塊中。也就是說，數據庫服務器的數據文件，或者數據表，就好像一個個抽屜，數據庫是按先后順序一條記錄一條記錄地從上到下存放數據。當整個表的容量逐漸增加時，該表相應的速度就會非常慢。
在剛開始的時候，人們想到了利用鏃表的方式來提高這個性能。也就是說，把整個抽屜分成幾排，然后每排給他們歸一類，如按辦圖書卡時的年齡進行分類，10歲以下的一類，10歲到15歲的一類等等。如此的話，在存讀者信息的時候，就不會簡單的按照辦卡時間來存儲，而是按照類別來存儲。如果是屬于10歲到15歲整個類，就會被物理的存儲在同一個系列的塊中。如此的話，就可以分類查找信息的速度。如果可以按類別查找數據信息，速度會非常快。
但是，隨著數據庫中的鏃塊增加，會影響數據庫的整體運行性能。這個問題發生之后，數據庫開發人員又想到了利用哈希函數來解決這個問題。哈希函數將會給定一個數值用來限定鏃塊數的數量的預計范圍。
也就是說，現在我們要建立一個圖書館用戶的表格，我們可以利用圖書卡的卡號作為鏃主鍵將有利于數據的存儲分布。但是，當讀者增加時，就需要使用一個哈希函數來約束鏃塊的數量。
不過Oracle數據庫在使用鏃技術來優化大表數據查詢之外，還采用了另外一種獨有的技術，即分區表的形式，來提高用戶對于大表的查詢效率。
在Oracle數據庫中，可以將一個大表分開放置在幾個邏輯分區中，或者是將一個大表分成幾張小表。在查詢時，即可以單獨的對這些小表進行查詢，而且，也可以利用union all參數進行一起查詢。
如在設計銷售訂單管理系統時，我們可以按年度把銷售訂單表分割成幾張小表，如此的話，后續的查詢效率會比一張大表高很多。不過，這個技術的應用，關鍵在于如何對表進行分割，以及如何把表放置在幾個邏輯分區中，這需要有一定經驗的數據庫設計工程師才能設計出一個好的方案。關于這方面的內容，在后續的文章中，筆者會有所闡述。
