我們再來看重新定義JOIN后如何能夠提高運算性能，先看外鍵式JOIN的情況。

設有兩個表：

其中sales表中的productid是指向products表中id字段的外鍵，id是products表的主鍵。

現在我們想計算銷售額有多少(為簡化討論，就不再設定條件了)，用SQL寫出來：

SELECT SUM(sales.quantity*products.price) FROM sales JOIN products ON sales.productid=products.id 

基于笛卡爾積定義的JOIN，原則上只能兩層循環全遍歷來計算，不過這個計算量實在太大，關系數據庫一般采用HASH分段方法優化，即分別計算兩表關聯字段的HASH值，將HASH同值記錄拼到一起再做小范圍遍歷。網上有很多文章介紹這個算法，這里就不詳述了。這樣做后的復雜度能顯著降低，但仍然要做多次HASH值計算和比對。

一

我們再用前述的簡化的JOIN語法寫出這個運算：

SELECT SUM(quantity*productid.price) FROM sales 

而這個寫法其實也就預示了它還可以有更好的優化方案，下面來看看怎樣實現。

二

我們先考慮全內存的情況，如果所有數據都能夠裝入內存，我們可以實現外鍵指針化。

將事實表sales中的外鍵字段productid，轉換成指向維表products記錄的指針，即productid的取值就已經是某個products表中的記錄，那么就可以直接引用記錄的字段進行計算了。

用SQL不方便描述這個運算的細節過程了，我們采用過程式語法、并用文件作為數據源來說明計算過程：

1. P=file("products.txt").import()

讀入商品信息表P

2. P.index(id)

為P的主鍵id建立索引方便查找

3. S=file("sales.txt").import()

讀入商品銷售記錄S

4. S.switch(productid,P:id)

將S中的productid字段根據P的主鍵轉換成P的記錄

5. S.sum(quantity*productid.price)

計算銷售額。productid字段取值已經轉換為對象，可以直接引用其price字段

上面算法中，第2步建主鍵索引一般也是用HASH辦法，對id計算HASH值，第4步轉換指針還是計算productid的HASH值與P的HASH索引表對比。這樣的話，如果只做一次關聯運算，指針化的方案和傳統HASH分段方案的計算量基本上一樣，沒有根本優勢。

但不同的是，如果數據能在內存中放下，這個指針一旦建立起來之后可以復用，也就是說第2和第4步只要做一次，下次再做關于這兩個字段的關聯運算時就不必再計算HASH值和比對了，性能就能大幅提高。而關系代數體系下沒有對象指針這個概念，并且基于笛卡爾積定義的JOIN運算也無法假定外鍵指向記錄的***性，沒辦法使用外鍵指針化的方法，每次關聯時都要計算HASH值并比對。

而且，如果事實表中有多個外鍵分別指向多個維表，傳統的HASH分段JOIN方案每次只能解析掉一個，有N個JOIN要執行N遍動作，每次關聯后都需要保持中間結果供下一輪使用，計算過程復雜得多，數據也會被遍歷多次。而外鍵指針化方案在面對多個外鍵時，只要對事實表遍歷一次， 沒有中間結果，計算過程要清晰很多。

還有一點，內存本來應當是很適合并行計算的，但HASH分段JOIN算法卻不容易并行。即使把數據分段并行計算HASH值，但要把相同HASH值的記錄歸聚到一起供下一輪比對，就會發生共享資源沖突的事情，這會把并行計算的優勢完全抵消掉。而外鍵式JOIN模型下，關聯兩表的地位不對等，明確區分出維表和事實表后，只要簡單地將事實表分段就可以并行計算。

將HASH分段技術參照外鍵屬性方案進行改造后，也能一定程度地改善多外鍵一次解析和并行能力，有些數據庫能在工程層面上實施這種優化。不過，這種優化在只有兩個表JOIN時問題不大，在有很多表及各種JOIN混在一起時，數據庫并不容易識別出應當把哪個表當作事實表去并行遍歷、而把其它表當作維表建立HASH索引，這時優化并不總是有效的。所以我們經常會發現當JOIN的表變多時性能會急劇下降的現象(常常到四五個表時就會發生，結果集并無顯著增大)。而從JOIN模型上引入外鍵概念后，將這種JOIN專門處理時，就總能分清事實表和維表，更多的JOIN表只會導致性能的線性下降。

內存數據庫是當前比較火熱的技術，但上述分析表明，采用SQL模型的內存數據庫在JOIN運算上是很難快起來的!