本文翻譯自Coding-Geek文章:《 How does a relational database work》。原文鏈接：http://coding-geek.com/how-databases-work/#Buffer-Replacement_strategies
本文翻譯瞭如下章節, 介紹數據庫查詢優化器的實現表連接的一個簡單實例：
簡單實例–Simplified example
我們已經看到了3種連接操作算法。現在我們來看一下如何連接包含個人完整信息的5張表的數據。一個人可能有如下信息：
- 多個手機號。
- 多個電子郵箱。
- 多個住址。
- 多個銀行賬戶。
換句話說，我們需要快速回答下面這個查詢語句(如何做連接)：
SELECT * from PERSON, MOBILES, MAILS,ADRESSES, BANK_ACCOUNTS
WHERE
PERSON.PERSON_ID = MOBILES.PERSON_ID
AND PERSON.PERSON_ID = MAILS.PERSON_ID
AND PERSON.PERSON_ID = ADRESSES.PERSON_ID
AND PERSON.PERSON_ID = BANK_ACCOUNTS.PERSON_ID作爲查詢優化器，我們必須找到處理這些數據最合適的方式。現在有兩個問題：
1. 我應該爲每個連接條件選擇哪種連接方式？我已有有3種可用的連接算法(Hash Join, Merge Join, Nested Join),可使用0,1,2個索引(不考慮不同索引類型存在的差異)。
.
2. 我應該按怎樣的順序去執行多個連接操作？
例如，下圖展示了各種可能的聯表處理方式(涉及4張表的3次Join過程)。
下面是我提供的一種可行方案：
1. 我使用的是一種簡單粗暴的逼近最優的計算策略(譯者注：使用窮舉法)。
.
使用數據庫的統計數據，我計算出所有可行的聯表方案的成本，保留成本最優的一個。但是，可能的方案也許非常多，對於已經指定順序的連接操作，每條連接都有3種可選的方案：HashJoin，Merge Join, Nested Loop Join。對於給定順序的連接操作，前面的4張表就有3的4次方種連接方案。
.
聯表順序組合數是一個排序組合，在二叉樹上4張表有(2*4)!/(4+1)!種聯表順序組合。
爲簡化問題，我認爲總共有34*(2*4)!/(4+1)!種聯表處理方案。
.
不考慮極端情況，這也意味着有27 216種可能的處理方案。如果我考慮增加0,1,或者2個B+樹的索引，可能的處理方案就變成了210 000種。而且這還是一個非常簡單的查詢語句。
.
2. 現在，我已經感到沮喪，不想繼續往下幹了。
到此爲打住看起來很好，但是你無法獲取你想知道的知識。而我也需要錢來支付賬單(譯者注：爲了錢，難搞的事情也要搞下去。作者寫這邊文章有稿費？)。
我僅嘗試幾種方案，從中找出一個成本最低的方案。
因爲我不是超人，不無法計算每種方式的成本。我隨機選擇所有方案的一個子集，計算子集中方案的成本，找出最優的。
我通過幾條規則來減少可能聯表方案的數量。有兩條規則：
我能使用邏輯規則，這些規則能去掉無用的選擇條件，但不會過濾掉很多可行的方案。例如：循環嵌套連接的內連接對象集必須是最小的那個數據集。
.
我接受找不到最優解的風險，通過一些激進的規則大量減少選擇條件。例如：如果一個對象集數據量很小，使用循環嵌套連接而不使用歸併連接。
在這個簡單的例子中，我找到這些可行條件結束。但是一個真實的查詢器還支持其它的關係連接操作，例如OUTER JOIN, CROSS JOIN, GROUP BY, ORDER BY, PROJECTION, UNION, INTERSECT, DISTINCT…。這意味着有更多可能的操作。
那麼，一個真實的數據庫是如何處理它們的呢？下一章節解釋。