【太經典】若是有人問你數據庫的原理，叫他看這篇文章

時間 2019-11-19

原文原文鏈接

博文原文地址：http://blog.jobbole.com/100349html

一提到關係型數據庫，我禁不住想：有些東西被忽視了。關係型數據庫無處不在，並且種類繁多，從小巧實用的 SQLite 到強大的 Teradata 。但不多有文章講解數據庫是如何工做的。你能夠本身谷歌/百度一下『關係型數據庫原理』，看看結果多麼的稀少【譯者注：百度爲您找到相關結果約1,850,000個…】，並且找到的那些文章都很短。如今若是你查找最近時髦的技術（大數據、NoSQL或JavaScript），你能找到更多深刻探討它們如何工做的文章。java

難道關係型數據庫已經太古老太無趣，除了大學教材、研究文獻和書籍之外，沒人願意講了嗎？mysql

做爲一個開發人員，我不喜歡用我不明白的東西。並且，數據庫已經使用了40年之久，必定有理由的。多年以來，我花了成百上千個小時來真正領會這些我天天都在用的、古怪的黑盒子。關係型數據庫很是有趣，由於它們是基於實用並且可複用的概念。若是你對了解一個數據庫感興趣，可是從未有時間或意願來刻苦鑽研這個內容普遍的課題，你應該喜歡這篇文章。算法

雖然本文標題很明確，但個人目的並非講如何使用數據庫。所以，你應該已經掌握怎麼寫一個簡單的 join query（聯接查詢）和CRUD操做（建立讀取更新刪除），不然你可能沒法理解本文。這是惟一須要你瞭解的，其餘的由我來說解。sql

我會從一些計算機科學方面的知識談起，好比時間複雜度。我知道有些人討厭這個概念，可是沒有它你就不能理解數據庫內部的巧妙之處。因爲這是個很大的話題，我將集中探討我認爲必要的內容：數據庫處理SQL查詢的方式。我僅僅介紹數據庫背後的基本概念，以便在讀完本文後你會對底層到底發生了什麼有個很好的瞭解。數據庫

【譯者注：關於時間複雜度。計算機科學中，算法的時間複雜度是一個函數，它定量描述了該算法的運行時間。若是不瞭解這個概念建議先看看維基或百度百科，對於理解文章下面的內容頗有幫助】apache

因爲本文是個長篇技術文章，涉及到不少算法和數據結構知識，你盡能夠慢慢讀。有些概念比較難懂，你能夠跳過，不影響理解總體內容。編程

這篇文章大約分爲3個部分：api

底層和上層數據庫組件概況
查詢優化過程概況
事務和緩衝池管理概況

回到基礎

好久好久之前（在一個遙遠而又遙遠的星系……)，開發者必須確切地知道他們的代碼須要多少次運算。他們把算法和數據結構牢記於心，由於他們的計算機運行緩慢，沒法承受對CPU和內存的浪費。緩存

在這一部分，我將提醒你們一些這類的概念，由於它們對理解數據庫相當重要。我還會介紹數據庫索引的概念。

O(1) vs O(n^2)

現今不少開發者不關心時間複雜度……他們是對的。

可是當你應對大量的數據（我說的可不僅是成千上萬哈）或者你要爭取毫秒級操做，那麼理解這個概念就很關鍵了。並且你猜怎麼着，數據庫要同時處理這兩種情景！我不會佔用你太長時間，只要你能明白這一點就夠了。這個概念在下文會幫助咱們理解什麼是基於成本的優化。

概念

時間複雜度用來檢驗某個算法處理必定量的數據要花多長時間。爲了描述這個複雜度，計算機科學家使用數學上的『簡明解釋算法中的大O符號』。這個表示法用一個函數來描述算法處理給定的數據須要多少次運算。

好比，當我說『這個算法是適用 O(某函數())』，個人意思是對於某些數據，這個算法須要某函數(數據量) 次運算來完成。

重要的不是數據量，而是當數據量增長時運算如何增長。時間複雜度不會給出確切的運算次數，可是給出的是一種理念。

圖中能夠看到不一樣類型的複雜度的演變過程，我用了對數尺來建這個圖。具體點兒說，數據量以很快的速度從1條增加到10億條。咱們可獲得以下結論：

綠：O(1)或者叫常數階複雜度，保持爲常數（要不人家就不會叫常數階複雜度了）。
紅：O(log(n))對數階複雜度，即便在十億級數據量時也很低。
粉：最糟糕的複雜度是 O(n^2)，平方階複雜度，運算數快速膨脹。
黑和藍：另外兩種複雜度（的運算數也是）快速增加。

例子

數據量低時，O(1) 和 O(n^2)的區別能夠忽略不計。好比，你有個算法要處理2000條元素。

O(1) 算法會消耗 1 次運算
O(log(n)) 算法會消耗 7 次運算
O(n) 算法會消耗 2000 次運算
O(n*log(n)) 算法會消耗 14,000 次運算
O(n^2) 算法會消耗 4,000,000 次運算

O(1) 和 O(n^2) 的區別彷佛很大（4百萬）,但你最多損失 2 毫秒，只是一眨眼的功夫。確實，當今處理器每秒可處理上億次的運算。這就是爲何性能和優化在不少IT項目中不是問題。

我說過，面臨海量數據的時候，瞭解這個概念依然很重要。若是這一次算法須要處理 1,000,000 條元素（這對數據庫來講也不算大）。

O(1) 算法會消耗 1 次運算
O(log(n)) 算法會消耗 14 次運算
O(n) 算法會消耗 1,000,000 次運算
O(n*log(n)) 算法會消耗 14,000,000 次運算
O(n^2) 算法會消耗 1,000,000,000,000 次運算

我沒有具體算過，但我要說，用O(n^2) 算法的話你有時間喝杯咖啡（甚至再續一杯！）。若是在數據量後面加個0，那你就能夠去睡大覺了。

繼續深刻

爲了讓你能明白

搜索一個好的哈希表會獲得 O(1) 複雜度
- 搜索一個均衡的樹會獲得 O(log(n)) 複雜度
- 搜索一個陣列會獲得 O(n) 複雜度
- 最好的排序算法具備 O(n*log(n)) 複雜度
- 糟糕的排序算法具備 O(n^2) 複雜度

注：在接下來的部分，咱們將會研究這些算法和數據結構。

有多種類型的時間複雜度

通常狀況場景
最佳狀況場景
最差狀況場景

時間複雜度常常處於最差狀況場景。

這裏我只探討時間複雜度，但複雜度還包括：

算法的內存消耗
算法的磁盤 I/O 消耗

固然還有比 n^2 更糟糕的複雜度，好比：

n^4：差勁！我將要提到的一些算法具有這種複雜度。
3^n：更差勁！本文中間部分研究的一些算法中有一個具有這種複雜度（並且在不少數據庫中還真的使用了）。
階乘 n：你永遠得不到結果，即使在少許數據的狀況下。
n^n：若是你發展到這種複雜度了，那你應該問問本身IT是否是你的菜。

注：我並無給出『大O表示法』的真正定義，只是利用這個概念。能夠看看維基百科上的這篇文章。

合併排序

當你要對一個集合排序時你怎麼作？什麼？調用 sort() 函數……好吧，算你對了……可是對於數據庫，你須要理解這個 sort() 函數的工做原理。

優秀的排序算法有好幾個，我側重於最重要的一種：合併排序。你如今可能還不瞭解數據排序有什麼用，但看完查詢優化部分後你就會知道了。再者，合併排序有助於咱們之後理解數據庫常見的聯接操做，即合併聯接。

合併

與不少有用的算法相似，合併排序基於這樣一個技巧：將 2 個大小爲 N/2 的已排序序列合併爲一個 N 元素已排序序列僅須要 N 次操做。這個方法叫作合併。

咱們用個簡單的例子來看看這是什麼意思：

經過此圖你能夠看到，在 2 個 4元素序列裏你只須要迭代一次，就能構建最終的8元素已排序序列，由於兩個4元素序列已經排好序了：

1) 在兩個序列中，比較當前元素（當前=頭一次出現的第一個）
2) 而後取出最小的元素放進8元素序列中
3) 找到（兩個）序列的下一個元素，(比較後)取出最小的
重複一、二、3步驟，直到其中一個序列中的最後一個元素
而後取出另外一個序列剩餘的元素放入8元素序列中。

這個方法之因此有效，是由於兩個4元素序列都已經排好序，你不須要再『回到』序列中查找比較。

【譯者注：合併排序詳細原理，其中一個動圖（原圖較長，我作了刪減）清晰的演示了上述合併排序的過程，而原文的敘述彷佛沒有這麼清晰，不動戳大。】

既然咱們明白了這個技巧，下面就是個人合併排序僞代碼。

array mergeSort(array a)

if(length(a)==1)

return a[0];

end if

//recursive calls

[left_array right_array] := split_into_2_equally_sized_arrays(a);

array new_left_array := mergeSort(left_array);

array new_right_array := mergeSort(right_array);

//merging the 2 small ordered arrays into a big one

array result := merge(new_left_array,new_right_array);

return result;

合併排序是把問題拆分爲小問題，經過解決小問題來解決最初的問題（注：這種算法叫分治法，即『分而治之、各個擊破』）。若是你不懂，不用擔憂，我第一次接觸時也不懂。若是能幫助你理解的話，我認爲這個算法是個兩步算法：

拆分階段，將序列分爲更小的序列
排序階段，把小的序列合在一塊兒（使用合併算法）來構成更大的序列

拆分階段

在拆分階段過程當中，使用3個步驟將序列分爲一元序列。步驟數量的值是 log(N) （由於 N=8, log(N)=3）。【譯者注：底數爲2，下文有說明】

我怎麼知道這個的？

我是天才！一句話：數學。道理是每一步都把原序列的長度除以2，步驟數就是你能把原序列長度除以2的次數。這正好是對數的定義（在底數爲2時）。

排序階段

在排序階段，你從一元序列開始。在每個步驟中，你應用屢次合併操做，成本一共是 N=8 次運算。

第一步，4 次合併，每次成本是 2 次運算。
第二步，2 次合併，每次成本是 4 次運算。
第三步，1 次合併，成本是 8 次運算。

由於有 log(N) 個步驟，總體成本是 N*log(N) 次運算。

【譯者注：這個完整的動圖演示了拆分和排序的全過程，不動戳大。】

合併排序的強大之處

爲何這個算法如此強大？

由於：

你能夠更改算法，以便於節省內存空間，方法是不建立新的序列而是直接修改輸入序列。

注：這種算法叫『原地算法』(in-place algorithm)

你能夠更改算法，以便於同時使用磁盤空間和少許內存而避免巨量磁盤 I/O。方法是隻向內存中加載當前處理的部分。在僅僅100MB的內存緩衝區內排序一個幾個GB的表時，這是個很重要的技巧。

注：這種算法叫『外部排序』(external sorting)。

你能夠更改算法，以便於在多處理器/多線程/多服務器上運行。

好比，分佈式合併排序是Hadoop（那個著名的大數據框架）的關鍵組件之一。

這個算法能夠點石成金（事實如此！）

這個排序算法在大多數（若是不是所有的話）數據庫中使用，可是它並非惟一算法。若是你想多瞭解一些，你能夠看看這篇論文，探討的是數據庫中經常使用排序算法的優點和劣勢。

陣列，樹和哈希表

既然咱們已經瞭解了時間複雜度和排序背後的理念，我必需要向你介紹3種數據結構了。這個很重要，由於它們是現代數據庫的支柱。我還會介紹數據庫索引的概念。

陣列

二維陣列是最簡單的數據結構。一個表能夠看做是個陣列，好比：

這個二維陣列是帶有行與列的表：

每一個行表明一個主體
列用來描述主體的特徵
每一個列保存某一種類型對數據（整數、字符串、日期……）

雖然用這個方法保存和視覺化數據很棒，可是當你要查找特定的值它就很糟糕了。舉個例子，若是你要找到全部在 UK 工做的人，你必須查看每一行以判斷該行是否屬於 UK 。這會形成 N 次運算的成本（N 等於行數），還不賴嘛，可是有沒有更快的方法呢？這時候樹就能夠登場了（或開始起做用了）。

樹和數據庫索引

二叉查找樹是帶有特殊屬性的二叉樹，每一個節點的關鍵字必須：

比保存在左子樹的任何鍵值都要大
比保存在右子樹的任何鍵值都要小

【譯者注：binary search tree，二叉查找樹/二叉搜索樹，或稱 Binary Sort Tree 二叉排序樹。見百度百科】

概念

這個樹有 N=15 個元素。比方說我要找208：

我從鍵值爲 136 的根開始，由於 136<208，我去找節點136的右子樹。
398>208，因此我去找節點398的左子樹
250>208，因此我去找節點250的左子樹
200<208，因此我去找節點200的右子樹。可是 200 沒有右子樹，值不存在（由於若是存在，它會在 200 的右子樹）

如今比方說我要找40

我從鍵值爲136的根開始，由於 136>40，因此我去找節點136的左子樹。
80>40，因此我去找節點 80 的左子樹
40=40，節點存在。我抽取出節點內部行的ID（圖中沒有畫）再去表中查找對應的 ROW ID。
知道 ROW ID我就知道了數據在表中對精確位置，就能夠當即獲取數據。

最後，兩次查詢的成本就是樹內部的層數。若是你仔細閱讀了合併排序的部分，你就應該明白一共有 log(N)層。因此這個查詢的成本是 log(N)，不錯啊！

回到咱們的問題

上文說的很抽象，咱們回來看看咱們的問題。此次不用傻傻的數字了，想象一下前表中表明某人的國家的字符串。假設你有個樹包含表中的列『country』：

若是你想知道誰在 UK 工做
你在樹中查找表明 UK 的節點
在『UK 節點』你會找到 UK 員工那些行的位置

此次搜索只需 log(N) 次運算，而若是你直接使用陣列則須要 N 次運算。你剛剛想象的就是一個數據庫索引。

B+樹索引

查找一個特定值這個樹挺好用，可是當你須要查找兩個值之間的多個元素時，就會有大麻煩了。你的成本將是 O(N)，由於你必須查找樹的每個節點，以判斷它是否處於那 2 個值之間（例如，對樹使用中序遍歷）。並且這個操做不是磁盤I/O有利的，由於你必須讀取整個樹。咱們須要找到高效的範圍查詢方法。爲了解決這個問題，現代數據庫使用了一種修訂版的樹，叫作B+樹。在一個B+樹裏：

只有最底層的節點（葉子節點）才保存信息（相關表的行位置）
其它節點只是在搜索中用來指引到正確節點的。

【譯者注：參考 B+樹，二叉樹遍歷維基百科】

你能夠看到，節點更多了（多了兩倍）。確實，你有了額外的節點，它們就是幫助你找到正確節點的『決策節點』（正確節點保存着相關表中行的位置）。可是搜索複雜度仍是在 O(log(N))（只多了一層）。一個重要的不一樣點是，最底層的節點是跟後續節點相鏈接的。

用這個 B+樹，假設你要找40到100間的值：

你只須要找 40（若40不存在則找40以後最貼近的值），就像你在上一個樹中所作的那樣。
而後用那些鏈接來收集40的後續節點，直到找到100。

比方說你找到了 M 個後續節點，樹總共有 N 個節點。對指定節點的搜索成本是 log(N)，跟上一個樹相同。可是當你找到這個節點，你得經過後續節點的鏈接獲得 M 個後續節點，這須要 M 次運算。那麼此次搜索只消耗了 M+log(N) 次運算，區別於上一個樹所用的 N 次運算。此外，你不須要讀取整個樹（僅須要讀 M+log(N) 個節點）,這意味着更少的磁盤訪問。若是 M 很小（好比 200 行）而且 N 很大（1,000,000），那結果就是天壤之別了。

然而還有新的問題（又來了！）。若是你在數據庫中增長或刪除一行（從而在相關的 B+樹索引裏）：

你必須在B+樹中的節點之間保持順序，不然節點會變得一團糟，你沒法從中找到想要的節點。
你必須儘量下降B+樹的層數，不然 O(log(N)) 複雜度會變成 O(N)。

換句話說，B+樹須要自我整理和自我平衡。謝天謝地，咱們有智能刪除和插入。可是這樣也帶來了成本：在B+樹中，插入和刪除操做是 O(log(N)) 複雜度。因此有些人聽到過使用太多索引不是個好主意這類說法。沒錯，你減慢了快速插入/更新/刪除表中的一個行的操做，由於數據庫須要以代價高昂的每索引 O(log(N)) 運算來更新表的索引。再者，增長索引意味着給事務管理器帶來更多的工做負荷（在本文結尾咱們會探討這個管理器）。

想了解更多細節，你能夠看看 Wikipedia 上這篇關於B+樹的文章。若是你想要數據庫中實現B+樹的例子，看看MySQL核心開發人員寫的這篇文章和這篇文章。兩篇文章都致力於探討 innoDB(MySQL引擎)如何處理索引。

哈希表

咱們最後一個重要的數據結構是哈希表。當你想快速查找值時，哈希表是很是有用的。並且，理解哈希表會幫助咱們接下來理解一個數據庫常見的聯接操做，叫作『哈希聯接』。這個數據結構也被數據庫用來保存一些內部的東西（好比鎖表或者緩衝池，咱們在下文會研究這兩個概念）。

哈希表這種數據結構能夠用關鍵字來快速找到一個元素。爲了構建一個哈希表，你須要定義：

元素的關鍵字
- 關鍵字的哈希函數。關鍵字計算出來的哈希值給出了元素的位置（叫作哈希桶）。
- 關鍵字比較函數。一旦你找到正確的哈希桶，你必須用比較函數在桶內找到你要的元素。

一個簡單的例子

咱們來看一個形象化的例子：

這個哈希表有10個哈希桶。由於我懶，我只給出5個桶，可是我知道你很聰明，因此我讓你想象其它的5個桶。我用的哈希函數是關鍵字對10取模，也就是我只保留元素關鍵字的最後一位，用來查找它的哈希桶：

若是元素最後一位是 0，則進入哈希桶0，
若是元素最後一位是 1，則進入哈希桶1，
若是元素最後一位是 2，則進入哈希桶2，
…我用的比較函數只是判斷兩個整數是否相等。

【譯者注：取模運算】

比方說你要找元素 78：

哈希表計算 78 的哈希碼，等於 8。
查找哈希桶 8，找到的第一個元素是 78。
返回元素 78。
查詢僅耗費了 2 次運算（1次計算哈希值，另外一次在哈希桶中查找元素）。

如今，比方說你要找元素 59：

哈希表計算 59 的哈希碼，等於9。
查找哈希桶 9，第一個找到的元素是 99。由於 99 不等於 59，那麼 99 不是正確的元素。
用一樣的邏輯，查找第二個元素(9)，第三個(79)，……，最後一個(29)。
元素不存在。
搜索耗費了 7 次運算。

一個好的哈希函數

你能夠看到，根據你查找的值，成本並不相同。

若是我把哈希函數改成關鍵字對 1,000,000 取模（就是說取後6位數字），第二次搜索只消耗一次運算，由於哈希桶 00059 裏面沒有元素。真正的挑戰是找到好的哈希函數，讓哈希桶裏包含很是少的元素。

在個人例子裏，找到一個好的哈希函數很容易，但這是個簡單的例子。當關鍵字是下列形式時，好的哈希函數就更難找了：

1 個字符串（好比一我的的姓）
2 個字符串（好比一我的的姓和名）
2 個字符串和一個日期（好比一我的的姓、名和出生年月日）
…

若是有了好的哈希函數，在哈希表裏搜索的時間複雜度是 O(1)。

陣列 vs 哈希表

爲何不用陣列呢？

嗯，你問得好。

一個哈希表能夠只裝載一半到內存，剩下的哈希桶能夠留在硬盤上。
用陣列的話，你須要一個連續內存空間。若是你加載一個大表，很難分配足夠的連續內存空間。
用哈希表的話，你能夠選擇你要的關鍵字（好比，一我的的國家和姓氏）。

想要更詳細的信息，你能夠閱讀我在Java HashMap 上的文章，是關於高效哈希表實現的。你不須要了解Java就能理解文章裏的概念。

全局概覽

咱們已經瞭解了數據庫內部的基本組件，如今咱們須要回來看看數據庫的全貌了。

數據庫是一個易於訪問和修改的信息集合。不過簡單的一堆文件也能達到這個效果。事實上，像SQLite這樣最簡單的數據庫也只是一堆文件而已，但SQLite是精心設計的一堆文件，由於它容許你：

使用事務來確保數據的安全和一致性
快速處理百萬條以上的數據

數據庫通常能夠用以下圖形來理解：

撰寫這部分以前，我讀過不少書/論文，它們都以本身的方式描述數據庫。因此，我不會特別關注如何組織數據庫或者如何命名各類進程，由於我選擇了本身的方式來描述這些概念以適應本文。區別就是不一樣的組件，整體思路爲：數據庫是由多種互相交互的組件構成的。

核心組件：

進程管理器（process manager）：不少數據庫具有一個須要妥善管理的進程/線程池。再者，爲了實現納秒級操做，一些現代數據庫使用本身的線程而不是操做系統線程。
網絡管理器（network manager）：網路I/O是個大問題，尤爲是對於分佈式數據庫。因此一些數據庫具有本身的網絡管理器。
文件系統管理器（File system manager）：磁盤I/O是數據庫的首要瓶頸。具有一個文件系統管理器來完美地處理OS文件系統甚至取代OS文件系統，是很是重要的。
內存管理器（memory manager）：爲了不磁盤I/O帶來的性能損失，須要大量的內存。可是若是你要處理大容量內存你須要高效的內存管理器，尤爲是你有不少查詢同時使用內存的時候。
安全管理器（Security Manager）：用於對用戶的驗證和受權。
客戶端管理器（Client manager）：用於管理客戶端鏈接。
……

工具：

備份管理器（Backup manager）：用於保存和恢復數據。
復原管理器（Recovery manager）：用於崩潰後重啓數據庫到一個一致狀態。
監控管理器（Monitor manager）：用於記錄數據庫活動信息和提供監控數據庫的工具。
Administration管理器（Administration manager）：用於保存元數據（好比表的名稱和結構），提供管理數據庫、模式、表空間的工具。【譯者注：好吧，我真的不知道Administration manager該翻譯成什麼，有知道的麻煩告知，不勝感激……】
……

查詢管理器：

查詢解析器（Query parser）：用於檢查查詢是否合法
查詢重寫器（Query rewriter）：用於預優化查詢
查詢優化器（Query optimizer）：用於優化查詢
查詢執行器（Query executor）：用於編譯和執行查詢

數據管理器：

事務管理器（Transaction manager）：用於處理事務
緩存管理器（Cache manager）：數據被使用以前置於內存，或者數據寫入磁盤以前置於內存
數據訪問管理器（Data access manager）：訪問磁盤中的數據

在本文剩餘部分，我會集中探討數據庫如何經過以下進程管理SQL查詢的：

客戶端管理器
查詢管理器
數據管理器（含復原管理器）

客戶端管理器

客戶端管理器是處理客戶端通訊的。客戶端能夠是一個（網站）服務器或者一個最終用戶或最終應用。客戶端管理器經過一系列知名的API（JDBC, ODBC, OLE-DB …）提供不一樣的方式來訪問數據庫。

客戶端管理器也提供專有的數據庫訪問API。

當你鏈接到數據庫時：

管理器首先檢查你的驗證信息（用戶名和密碼），而後檢查你是否有訪問數據庫的受權。這些權限由DBA分配。
而後，管理器檢查是否有空閒進程（或線程）來處理你對查詢。
管理器還會檢查數據庫是否負載很重。
管理器可能會等待一下子來獲取須要的資源。若是等待時間達到超時時間，它會關閉鏈接並給出一個可讀的錯誤信息。
而後管理器會把你的查詢送給查詢管理器來處理。
由於查詢處理進程不是『不全則無』的，一旦它從查詢管理器獲得數據，它會把部分結果保存到一個緩衝區而且開始給你發送。
若是遇到問題，管理器關閉鏈接，向你發送可讀的解釋信息，而後釋放資源。

查詢管理器

這部分是數據庫的威力所在，在這部分裏，一個寫得糟糕的查詢能夠轉換成一個快速執行的代碼，代碼執行的結果被送到客戶端管理器。這個多步驟操做過程以下：

查詢首先被解析並判斷是否合法
而後被重寫，去除了無用的操做而且加入預優化部分
接着被優化以便提高性能，並被轉換爲可執行代碼和數據訪問計劃。
而後計劃被編譯
最後，被執行

這裏我不會過多探討最後兩步，由於它們不過重要。

看完這部分後，若是你須要更深刻的知識，我建議你閱讀：

關於成本優化的初步研究論文(1979)：關係型數據庫系統存取路徑選擇。這個篇文章只有12頁，並且具有計算機通常水平就能理解。
很是好、很是深刻的 DB2 9.X 如何優化查詢的介紹
很是好的PostgreSQL如何優化查詢的介紹。這是一篇最通俗易懂的文檔，由於它講的是『咱們來看看在這種狀況下，PostgreSQL給出了什麼樣的查詢計劃』，而不是『咱們來看看PostgreSQL用的什麼算法』。
官方SQLite優化文檔。『易於』閱讀，由於SQLite用的是簡單規則。再者，這是惟一真正解釋SQLite如何工做的官方文檔。
很是好的SQL Server 2005 如何優化查詢的介紹
Oracle 12c 優化白皮書
2篇查詢優化的教程，第一篇第二篇。教程來自《數據庫系統概念》的做者，很好的讀物，集中討論磁盤I/O，可是要求具備很好的計算機科學水平。
另外一個原理教程，這篇教程我以爲更易懂，不過它僅關注聯接運算符（join operators）和磁盤I/O。

查詢解析器

每一條SQL語句都要送到解析器來檢查語法，若是你的查詢有錯，解析器將拒絕該查詢。好比，若是你寫成」SLECT …」而不是「SELECT …」，那就沒有下文了。

但這還不算完，解析器還會檢查關鍵字是否使用正確的順序，好比 WHERE 寫在 SELECT 以前會被拒絕。

而後，解析器要分析查詢中的表和字段，使用數據庫元數據來檢查：

表是否存在
表的字段是否存在
對某類型字段的運算是否可能（好比，你不能將整數和字符串進行比較，你不能對一個整數使用 substring() 函數）

接着，解析器檢查在查詢中你是否有權限來讀取（或寫入）表。再強調一次：這些權限由DBA分配。

在解析過程當中，SQL 查詢被轉換爲內部表示（一般是一個樹）。

若是一切正常，內部表示被送到查詢重寫器。

查詢重寫器

在這一步，咱們已經有了查詢的內部表示，重寫器的目標是：

預優化查詢
避免沒必要要的運算
幫助優化器找到合理的最佳解決方案

重寫器按照一系列已知的規則對查詢執行檢測。若是查詢匹配一種模式的規則，查詢就會按照這條規則來重寫。下面是（可選）規則的非詳盡的列表：

視圖合併：若是你在查詢中使用視圖，視圖就會轉換爲它的 SQL 代碼。
子查詢扁平化：子查詢是很難優化的，所以重寫器會嘗試移除子查詢

例如：

MySQL

SELECT PERSON.*

FROM PERSON

WHERE PERSON.person_key IN

(SELECT MAILS.person_key

FROM MAILS

WHERE MAILS.mail LIKE 'christophe%');

會轉換爲：

MySQL

SELECT PERSON.*

FROM PERSON, MAILS

WHERE PERSON.person_key = MAILS.person_key

and MAILS.mail LIKE 'christophe%';

去除沒必要要的運算符：好比，若是你用了 DISTINCT，而其實你有 UNIQUE 約束（這自己就防止了數據出現重複），那麼 DISTINCT 關鍵字就被去掉了。
排除冗餘的聯接：若是相同的 JOIN 條件出現兩次，好比隱藏在視圖中的 JOIN 條件，或者因爲傳遞性產生的無用 JOIN，都會被消除。
常數計算賦值：若是你的查詢須要計算，那麼在重寫過程當中計算會執行一次。好比 WHERE AGE > 10+2 會轉換爲 WHERE AGE > 12 ， TODATE(「日期字符串」) 會轉換爲 datetime 格式的日期值。
（高級）分區裁剪（Partition Pruning）：若是你用了分區表，重寫器可以找到須要使用的分區。
（高級）物化視圖重寫（Materialized view rewrite）：若是你有個物化視圖匹配查詢謂詞的一個子集，重寫器將檢查視圖是否最新並修改查詢，令查詢使用物化視圖而不是原始表。
（高級）自定義規則：若是你有自定義規則來修改查詢（就像 Oracle policy），重寫器就會執行這些規則。
（高級）OLAP轉換：分析/加窗函數，星形聯接，ROLLUP 函數……都會發生轉換（但我不肯定這是由重寫器仍是優化器來完成，由於兩個進程聯繫很緊，必須看是什麼數據庫）。

【譯者注：物化視圖。謂詞，predicate，條件表達式的求值返回真或假的過程】

重寫後的查詢接着送到優化器，這時候好玩的就開始了。

統計

研究數據庫如何優化查詢以前咱們須要談談統計，由於沒有統計的數據庫是愚蠢的。除非你明確指示，數據庫是不會分析本身的數據的。沒有分析會致使數據庫作出（很是）糟糕的假設。

可是，數據庫須要什麼類型的信息呢？

我必須（簡要地）談談數據庫和操做系統如何保存數據。二者使用的最小單位叫作頁或塊（默認 4 或 8 KB）。這就是說若是你僅須要 1KB，也會佔用一個頁。要是頁的大小爲 8KB，你就浪費了 7KB。

回來繼續講統計！當你要求數據庫收集統計信息，數據庫會計算下列值：

表中行和頁的數量
表中每一個列中的：
惟一值
數據長度（最小，最大，平均）
數據範圍（最小，最大，平均）

表的索引信息

這些統計信息會幫助優化器估計查詢所需的磁盤 I/O、CPU、和內存使用

對每一個列的統計很是重要。
好比，若是一個表 PERSON 須要聯接 2 個列： LAST_NAME, FIRST_NAME。
根據統計信息，數據庫知道FIRST_NAME只有 1,000 個不一樣的值，LAST_NAME 有 1,000,000 個不一樣的值。
所以，數據庫就會按照 LAST_NAME, FIRST_NAME 聯接。
由於 LAST_NAME 不大可能重複，多數狀況下比較 LAST_NAME 的頭 2 、 3 個字符就夠了，這將大大減小比較的次數。

不過，這些只是基本的統計。你可讓數據庫作一種高級統計，叫直方圖。直方圖是列值分佈狀況的統計信息。例如：

出現最頻繁的值
分位數【譯者注：http://baike.baidu.com/view/1323572.htm】
…

這些額外的統計會幫助數據庫找到更佳的查詢計劃，尤爲是對於等式謂詞（例如： WHERE AGE = 18 ）或範圍謂詞（例如： WHERE AGE > 10 and AGE < 40），由於數據庫能夠更好的瞭解這些謂詞相關的數字類型數據行（注：這個概念的技術名稱叫選擇率）。

統計信息保存在數據庫元數據內，例如（非分區）表的統計信息位置：

Oracle： USER / ALL / DBA_TABLES 和 USER / ALL / DBA_TAB_COLUMNS
DB2： SYSCAT.TABLES 和 SYSCAT.COLUMNS

統計信息必須及時更新。若是一個表有 1,000,000 行而數據庫認爲它只有 500 行，沒有比這更糟糕的了。統計惟一的不利之處是須要時間來計算，這就是爲何數據庫大多默認狀況下不會自動計算統計信息。數據達到百萬級時統計會變得困難，這時候，你能夠選擇僅作基本統計或者在一個數據庫樣本上執行統計。

舉個例子，我參與的一個項目須要處理每表上億條數據的庫，我選擇只統計10%，結果形成了巨大的時間消耗。本例證實這是個糟糕的決定，由於有時候 Oracle 10G 從特定表的特定列中選出的 10% 跟所有 100% 有很大不一樣（對於擁有一億行數據的表，這種狀況極少發生）。此次錯誤的統計致使了一個本應 30 秒完成的查詢最後執行了 8 個小時，查找這個現象根源的過程簡直是個噩夢。這個例子顯示了統計的重要性。

注：固然了，每一個數據庫還有其特定的更高級的統計。若是你想了解更多信息，讀讀數據庫的文檔。話雖然這麼說，我已經盡力理解統計是如何使用的了，並且我找到的最好的官方文檔來自PostgreSQL。

查詢優化器

全部的現代數據庫都在用基於成本的優化（即CBO）來優化查詢。道理是針對每一個運算設置一個成本，經過應用成本最低廉的一系列運算，來找到最佳的下降查詢成本的方法。

爲了理解成本優化器的原理，我以爲最好用個例子來『感覺』一下這個任務背後的複雜性。這裏我將給出聯接 2 個表的 3 個方法，咱們很快就能看到即使一個簡單的聯接查詢對於優化器來講都是個噩夢。以後，咱們會了解真正的優化器是怎麼作的。

對於這些聯接操做，我會專一於它們的時間複雜度，可是，數據庫優化器計算的是它們的 CPU 成本、磁盤 I/O 成本、和內存需求。時間複雜度和 CPU 成本的區別是，時間成本是個近似值（給我這樣的懶傢伙準備的）。而 CPU 成本，我這裏包括了全部的運算，好比：加法、條件判斷、乘法、迭代……還有呢：

每個高級代碼運算都要特定數量的低級 CPU 運算。
對於 Intel Core i七、Intel Pentium 四、AMD Opteron…等，（就 CPU 週期而言）CPU 的運算成本是不一樣的，也就是說它取決於 CPU 的架構。

使用時間複雜度就容易多了（至少對我來講），用它我也能瞭解到 CBO 的概念。因爲磁盤 I/O 是個重要的概念，我偶爾也會提到它。請牢記，大多數時候瓶頸在於磁盤 I/O 而不是 CPU 使用。

索引

在研究 B+樹的時候咱們談到了索引，要記住一點，索引都是已經排了序的。

僅供參考：還有其餘類型的索引，好比位圖索引，在 CPU、磁盤I/O、和內存方面與B+樹索引的成本並不相同。

另外，不少現代數據庫爲了改善執行計劃的成本，能夠僅爲當前查詢動態地生成臨時索引。

存取路徑

在應用聯接運算符（join operators）以前，你首先須要得到數據。如下就是得到數據的方法。

注：因爲全部存取路徑的真正問題是磁盤 I/O，我不會過多探討時間複雜度。

【譯者注：四種類型的Oracle索引掃描介紹】

全掃描

若是你讀過執行計劃，必定看到過『全掃描』（或只是『掃描』）一詞。簡單的說全掃描就是數據庫完整的讀一個表或索引。就磁盤 I/O 而言，很明顯全表掃描的成本比索引全掃描要高昂。

範圍掃描

其餘類型的掃描有索引範圍掃描，好比當你使用謂詞」 WHERE AGE > 20 AND AGE < 40 」的時候它就會發生。

固然，你須要在 AGE 字段上有索引才能用到索引範圍掃描。

在第一部分咱們已經知道，範圍查詢的時間成本大約是 log(N)+M，這裏 N 是索引的數據量，M 是範圍內估測的行數。多虧有了統計咱們才能知道 N 和 M 的值（注： M 是謂詞「 AGE > 20 AND AGE < 40 」的選擇率）。另外範圍掃描時，你不須要讀取整個索引，所以在磁盤 I/O 方面沒有全掃描那麼昂貴。

惟一掃描

若是你只須要從索引中取一個值你能夠用惟一掃描。

根據 ROW ID 存取

多數狀況下，若是數據庫使用索引，它就必須查找與索引相關的行，這樣就會用到根據 ROW ID 存取的方式。

例如，假如你運行：

MySQL

1	SELECT LASTNAME, FIRSTNAME from PERSON WHERE AGE = 28

若是 person 表的 age 列有索引，優化器會使用索引找到全部年齡爲 28 的人，而後它會去表中讀取相關的行，這是由於索引中只有 age 的信息而你要的是姓和名。

可是，假如你換個作法：

MySQL

1 2	SELECT TYPE_PERSON.CATEGORY from PERSON ,TYPE_PERSON WHERE PERSON.AGE = TYPE_PERSON.AGE

PERSON 表的索引會用來聯接 TYPE_PERSON 表，可是 PERSON 表不會根據行ID 存取，由於你並無要求這個表內的信息。

雖然這個方法在少許存取時表現很好，這個運算的真正問題實際上是磁盤 I/O。假如須要大量的根據行ID存取，數據庫也許會選擇全掃描。

其它路徑

我沒有列舉全部的存取路徑，若是你感興趣能夠讀一讀 Oracle文檔。其它數據庫裏也許叫法不一樣但背後的概念是同樣的。

聯接運算符

那麼，咱們知道如何獲取數據了，那如今就把它們聯接起來！

我要展示的是3個個經常使用聯接運算符：合併聯接（Merge join），哈希聯接（Hash Join）和嵌套循環聯接（Nested Loop Join）。可是在此以前，我須要引入新詞彙了：內關係和外關係（ inner relation and outer relation）【譯者注：「內關係和外關係」這個說法來源不明，跟查詢的「內聯接（INNER JOIN）、外聯接（OUTER JOIN）」不是一個概念。只查到百度百科詞條：關係數據庫裏提到「每一個表格（有時被稱爲一個關係）……」。其餘參考連接「Merge Join」「Hash Join」「Nested Loop Join」】。一個關係能夠是：

一個表
一個索引
上一個運算的中間結果（好比上一個聯接運算的結果）

當你聯接兩個關係時，聯接算法對兩個關係的處理是不一樣的。在本文剩餘部分，我將假定：

外關係是左側數據集
內關係是右側數據集

好比， A JOIN B 是 A 和 B 的聯接，這裏 A 是外關係，B 是內關係。

多數狀況下， A JOIN B 的成本跟 B JOIN A 的成本是不一樣的。

在這一部分，我還將假定外關係有 N 個元素，內關係有 M 個元素。要記住，真實的優化器經過統計知道 N 和 M 的值。

注：N 和 M 是關係的基數。【譯者注：基數】

嵌套循環聯接

嵌套循環聯接是最簡單的。

道理以下：

針對外關係的每一行
查看內關係裏的全部行來尋找匹配的行

下面是僞代碼：

nested_loop_join(array outer, array inner)

for each row a in outer

for each row b in inner

if (match_join_condition(a,b))

write_result_in_output(a,b)

end if

end for

因爲這是個雙迭代，時間複雜度是 O(N*M)。

在磁盤 I/O 方面，針對 N 行外關係的每一行，內部循環須要從內關係讀取 M 行。這個算法須要從磁盤讀取 N+ N*M 行。可是，若是內關係足夠小，你能夠把它讀入內存，那麼就只剩下 M + N 次讀取。這樣修改以後，內關係必須是最小的，由於它有更大機會裝入內存。

在CPU成本方面沒有什麼區別，可是在磁盤 I/O 方面，最好最好的，是每一個關係只讀取一次。

固然，內關係能夠由索引代替，對磁盤 I/O 更有利。

因爲這個算法很是簡單，下面這個版本在內關係太大沒法裝入內存時，對磁盤 I/O 更加有利。道理以下：

爲了不逐行讀取兩個關係，
你能夠成簇讀取，把（兩個關係裏讀到的）兩簇數據行保存在內存裏，
比較兩簇數據，保留匹配的，
而後從磁盤加載新的數據簇來繼續比較
直到加載了全部數據。

可能的算法以下：

// improved version to reduce the disk I/O.

nested_loop_join_v2(file outer, file inner)

for each bunch ba in outer

// ba is now in memory

for each bunch bb in inner

// bb is now in memory

for each row a in ba

for each row b in bb

if (match_join_condition(a,b))

write_result_in_output(a,b)

end if

end for

使用這個版本，時間複雜度沒有變化，可是磁盤訪問下降了：

用前一個版本，算法須要 N + N*M 次訪問（每次訪問讀取一行）。
用新版本，磁盤訪問變爲外關係的數據簇數量 + 外關係的數據簇數量 * 內關係的數據簇數量。
增長數據簇的尺寸，能夠下降磁盤訪問。

哈希聯接

哈希聯接更復雜，不過在不少場合比嵌套循環聯接成本低。

哈希聯接的道理是：

1) 讀取內關係的全部元素
2) 在內存裏建一個哈希表
3) 逐條讀取外關係的全部元素
4) （用哈希表的哈希函數）計算每一個元素的哈希值，來查找內關係裏相關的哈希桶內
5) 是否與外關係的元素匹配。

在時間複雜度方面我須要作些假設來簡化問題：

內關係被劃分紅 X 個哈希桶
哈希函數幾乎均勻地分佈每一個關係內數據的哈希值，就是說哈希桶大小一致。
外關係的元素與哈希桶內的全部元素的匹配，成本是哈希桶內元素的數量。

時間複雜度是 (M/X) * (N/X) + 建立哈希表的成本(M) + 哈希函數的成本 * N 。
若是哈希函數建立了足夠小規模的哈希桶，那麼複雜度就是 O(M+N)。

還有個哈希聯接的版本，對內存有利可是對磁盤 I/O 不夠有利。這回是這樣的：

1) 計算內關係和外關係雙方的哈希表
2) 保存哈希表到磁盤
3) 而後逐個哈希桶比較（其中一個讀入內存，另外一個逐行讀取）。

合併聯接

合併聯接是惟一產生排序的聯接算法。

注：這個簡化的合併聯接不區份內表或外表；兩個表扮演一樣的角色。可是真實的實現方式是不一樣的，好比當處理重複值時。

1.（可選）排序聯接運算：兩個輸入源都按照聯接關鍵字排序。

2.合併聯接運算：排序後的輸入源合併到一塊兒。

排序

咱們已經談到過合併排序，在這裏合併排序是個很好的算法（可是並不是最好的，若是內存足夠用的話，仍是哈希聯接更好）。

然而有時數據集已經排序了，好比：

若是表內部就是有序的，好比聯接條件裏一個索引組織表【譯者注： index-organized table 】
若是關係是聯接條件裏的一個索引
若是聯接應用在一個查詢中已經排序的中間結果

合併聯接

這部分與咱們研究過的合併排序中的合併運算很是類似。不過這一次呢，咱們不是從兩個關係裏挑選全部元素，而是隻挑選相同的元素。道理以下：

1) 在兩個關係中，比較當前元素（當前=頭一次出現的第一個）
2) 若是相同，就把兩個元素都放入結果，再比較兩個關係裏的下一個元素
3) 若是不一樣，就去帶有最小元素的關係裏找下一個元素（由於下一個元素可能會匹配）
4) 重複一、二、3步驟直到其中一個關係的最後一個元素。

由於兩個關係都是已排序的，你不須要『回頭去找』，因此這個方法是有效的。

該算法是個簡化版，由於它沒有處理兩個序列中相同數據出現屢次的狀況（即多重匹配）。真實版本『僅僅』針對本例就更加複雜，因此我才選擇簡化版。

若是兩個關係都已經排序，時間複雜度是 O(N+M)

若是兩個關係須要排序，時間複雜度是對兩個關係排序的成本：O(N*Log(N) + M*Log(M))

對於計算機極客，我給出下面這個可能的算法來處理多重匹配（注：對於這個算法我不保證100%正確）：

mergeJoin(relation a, relation b)

relation output

integer a_key:=0;

integer b_key:=0;

while (a[a_key]!=null and b[b_key]!=null)

if (a[a_key] < b[b_key])

a_key++;

else if (a[a_key] > b[b_key])

b_key++;

else //Join predicate satisfied

write_result_in_output(a[a_key],b[b_key])

//We need to be careful when we increase the pointers

if (a[a_key+1] != b[b_key])

b_key++;

end if

if (b[b_key+1] != a[a_key])

a_key++;

end if

if (b[b_key+1] == a[a_key] && b[b_key] == a[a_key+1])

b_key++;

a_key++;

end if

end while

哪一個算法最好？

若是有最好的，就不必弄那麼多種類型了。這個問題很難，由於不少因素都要考慮，好比：

空閒內存：沒有足夠的內存的話就跟強大的哈希聯接拜拜吧（至少是徹底內存中哈希聯接）。
兩個數據集的大小。好比，若是一個大表聯接一個很小的表，那麼嵌套循環聯接就比哈希聯接快，由於後者有建立哈希的高昂成本；若是兩個表都很是大，那麼嵌套循環聯接CPU成本就很高昂。
是否有索引：有兩個 B+樹索引的話，聰明的選擇彷佛是合併聯接。
結果是否須要排序：即便你用到的是未排序的數據集，你也可能想用成本較高的合併聯接（帶排序的），由於最終獲得排序的結果後，你能夠把它和另外一個合併聯接串起來（或者也許由於查詢用 ORDER BY/GROUP BY/DISTINCT 等操做符隱式或顯式地要求一個排序結果）。
關係是否已經排序：這時候合併聯接是最好的候選項。
聯接的類型：是等值聯接（好比 tableA.col1 = tableB.col2 ）？仍是內聯接？外聯接？笛卡爾乘積？或者自聯接？有些聯接在特定環境下是沒法工做的。
數據的分佈：若是聯接條件的數據是傾斜的（好比根據姓氏來聯接人，可是不少人同姓），用哈希聯接將是個災難，緣由是哈希函數將產生分佈極不均勻的哈希桶。
若是你但願聯接操做使用多線程或多進程。

想要更詳細的信息，能夠閱讀DB2, ORACLE 或 SQL Server)的文檔。

簡化的例子

咱們已經研究了 3 種類型的聯接操做。

如今，好比說咱們要聯接 5 個表，來得到一我的的所有信息。一我的能夠有：

多個手機號（MOBILES）
多個郵箱（MAILS）
多個地址（ADRESSES）
多個銀行帳號（BANK_ACCOUNTS）

換句話說，咱們須要用下面的查詢快速獲得答案：

MySQL

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

做爲一個查詢優化器，我必須找處處理數據最好的方法。但有 2 個問題：

每一個聯接使用那種類型？
我有 3 種可選（哈希、合併、嵌套），同時可能用到 0, 1 或 2 個索引（沒必要說還有多種類型的索引）。

按什麼順序執行聯接？
好比，下圖顯示了針對 4 個表僅僅 3 次聯接，可能採用的執行計劃：

那麼下面就是我可能採起的方法：

1) 採起粗暴的方式
用數據庫統計，計算每種可能的執行計劃的成本，保留最佳方案。可是，會有不少可能性。對於一個給定順序的聯接操做，每一個聯接有三種可能性：哈希、合併、嵌套，那麼總共就有 3^4 種可能性。肯定聯接的順序是個二叉樹的排列問題，會有 (2*4)!/(4+1)! 種可能的順序。對本例這個至關簡化了的問題，我最後會獲得 3^4*(2*4)!/(4+1)! 種可能。
拋開專業術語，那至關於 27,216 種可能性。若是給合併聯接加上使用 0,1 或 2 個 B+樹索引，可能性就變成了 210,000種。我是否是告訴過你這個查詢其實很是簡單嗎？

2) 我大叫一聲辭了這份工做
頗有誘惑力，可是這樣一來，你不會的到查詢結果，而我須要錢來付帳單。

3) 我只嘗試幾種執行計劃，挑一個成本最低的。
因爲不是超人，我不能算出全部計劃的成本。相反，我能夠武斷地從所有可能的計劃中選擇一個子集，計算它們的成本，把最佳的計劃給你。

4) 我用聰明的規則來下降可能性的數量
有兩種規則：
我能夠用『邏輯』規則，它能去除無用的可能性，可是沒法過濾大量的可能性。好比：『嵌套聯接的內關係必須是最小的數據集』。
我接受現實，不去找最佳方案，用更激進的規則來大大下降可能性的數量。好比：『若是一個關係很小，使用嵌套循環聯接，毫不使用合併或哈希聯接。』

在這個簡單的例子中，我最後獲得不少可能性。但現實世界的查詢還會有其餘關係運算符，像 OUTER JOIN, CROSS JOIN, GROUP BY, ORDER BY, PROJECTION, UNION, INTERSECT, DISTINCT … 這意味着更多的可能性。

那麼，數據庫是如何處理的呢？

動態編程，貪婪算法和啓發式算法

關係型數據庫會嘗試我剛剛提到的多種方法，優化器真正的工做是在有限時間裏找到一個好的解決方案。

多數時候，優化器找到的不是最佳的方案，而是一個『不錯』的

對於小規模的查詢，採起粗暴的方式是有可能的。可是爲了讓中等規模的查詢也能採起粗暴的方式，咱們有辦法避免沒必要要的計算，這就是動態編程。

動態編程

這幾個字背後的理念是，不少執行計劃是很是類似的。看看下圖這幾種計劃：

它們都有相同的子樹（A JOIN B），因此，沒必要在每一個計劃中計算這個子樹的成本，計算一次，保存結果，當再遇到這個子樹時重用。用更正規的說法，咱們面對的是個重疊問題。爲了不對部分結果的重複計算，咱們使用記憶法。

對於計算機極客，下面是我在先前給你的教程裏找到的一個算法。我不提供解釋，因此僅在你已經瞭解動態編程或者精通算法的狀況下閱讀（我提醒過你哦）：

procedure findbestplan(S)

if (bestplan[S].cost infinite)

return bestplan[S]

// else bestplan[S] has not been computed earlier, compute it now

if (S contains only 1 relation)

set bestplan[S].plan and bestplan[S].cost based on the best way

of accessing S /* Using selections on S and indices on S */

else for each non-empty subset S1 of S such that S1 != S

P1= findbestplan(S1)

P2= findbestplan(S - S1)

A = best algorithm for joining results of P1 and P2

cost = P1.cost + P2.cost + cost of A

if cost < bestplan[S].cost

bestplan[S].cost = cost

bestplan[S].plan = 『execute P1.plan; execute P2.plan;

join results of P1 and P2 using A』

return bestplan[S]

針對大規模查詢，你也能夠用動態編程方法，可是要附加額外的規則（或者稱爲啓發式算法）來減小可能性。

若是咱們僅分析一個特定類型的計劃（例如左深樹 left-deep tree，參考)，咱們獲得 n*2^n 而不是 3^n。

若是咱們加上邏輯規則來避免一些模式的計劃（像『若是一個表有針對指定謂詞的索引，就不要對錶嘗試合併聯接，要對索引』），就會在不給最佳方案形成過多傷害的前提下，減小可能性的數量。【譯者注：原文應該是有兩處筆誤： as=has, to=too】
若是咱們在流程裏增長規則（像『聯接運算先於其餘全部的關係運算』），也能減小大量的可能性。
……

貪婪算法

可是，優化器面對一個很是大的查詢，或者爲了儘快找到答案（然而查詢速度就快不起來了），會應用另外一種算法，叫貪婪算法。

原理是按照一個規則（或啓發）以漸進的方式制定查詢計劃。在這個規則下，貪婪算法逐步尋找最佳算法，先處理一條JOIN，接着每一步按照一樣規則加一條新的JOIN。

咱們來看個簡單的例子。好比一個針對5張表（A,B,C,D,E）4次JOIN 的查詢，爲了簡化咱們把嵌套JOIN做爲可能的聯接方式，按照『使用最低成本的聯接』規則。

直接從 5 個表裏選一個開始（好比 A）
計算每個與 A 的聯接（A 做爲內關係或外關係）
發現「A JOIN B」成本最低
計算每個與「A JOIN B」的結果聯接的成本（「A JOIN B」做爲內關係或外關係）
發現「(A JOIN B) JOIN C」成本最低
計算每個與「(A JOIN B) JOIN C」的結果聯接的成本 ……
最後肯定執行計劃「( ( (A JOIN B) JOIN C) JOIN D ) JOIN E )」

由於咱們是武斷地從表 A 開始，咱們能夠把一樣的算法用在 B，而後 C，而後 D, 而後 E。最後保留成本最低的執行計劃。

順便說一句，這個算法有個名字，叫『最近鄰居算法』。

拋開細節不談，只需一個良好的模型和一個 N*log(N) 複雜度的排序，問題就輕鬆解決了。這個算法的複雜度是 O(N*log(N)) ，對比一下徹底動態編程的 O(3^N)。若是你有個20個聯接的大型查詢，這意味着 26 vs 3,486,784,401 ，天壤之別！

這個算法的問題是，咱們作的假設是：找到 2 個表的最佳聯接方法，保留這個聯接結果，再聯接下一個表，就能獲得最低的成本。可是：

即便在 A, B, C 之間，A JOIN B 可得最低成本
(A JOIN C) JOIN B 也許比 (A JOIN B) JOIN C 更好。

爲了改善這一情況，你能夠屢次使用基於不一樣規則的貪婪算法，並保留最佳的執行計劃。

其餘算法

[ 若是你已經受夠了算法話題，就直接跳到下一部分。這部分對文章餘下的內容不重要。]【譯者注：我也很想把這段跳過去 -_- 】

不少計算機科學研究者熱衷於尋找最佳的執行計劃，他們常常爲特定問題或模式探尋更好的解決方案，好比：

若是查詢是星型聯接（一種多聯接查詢），某些數據庫使用一種特定的算法。
若是查詢是並行的，某些數據庫使用一種特定的算法。 ……

其餘算法也在研究之中，就是爲了替換在大型查詢中的動態編程算法。貪婪算法屬於一個叫作啓發式算法的你們族，它根據一條規則（或啓發），保存上一步找到的方法，『附加』到當前步驟來進一步搜尋解決方法。有些算法根據特定規則，一步步的應用規則但不老是保留上一步找到的最佳方法。它們統稱啓發式算法。

好比，基因算法就是一種：

一個方法表明一種可能的完整查詢計劃
每一步保留了 P 個方法（即計劃），而不是一個。
0) P 個計劃隨機建立
1) 成本最低的計劃纔會保留
2) 這些最佳計劃混合在一塊兒產生 P 個新的計劃
3) 一些新的計劃被隨機改寫
4) 1，2，3步重複 T 次
5) 而後在最後一次循環，從 P 個計劃裏獲得最佳計劃。

循環次數越多，計劃就越好。

這是魔術？不，這是天然法則：適者生存！

PostgreSQL 實現了基因算法，但我並無發現它是否是默認使用這種算法的。

數據庫中還使用了其它啓發式算法，像『模擬退火算法（Simulated Annealing）』、『交互式改良算法（Iterative Improvement）』、『雙階段優化算法（Two-Phase Optimization）』…..不過，我不知道這些算法當前是否在企業級數據庫應用了，仍是僅僅用在研究型數據庫。

若是想進一步瞭解，這篇研究文章介紹兩個更多可能的算法《數據庫查詢優化中聯接排序問題的算法綜述》，你能夠去閱讀一下。

真實的優化器

[ 這段不重要，能夠跳過 ]

然而，全部上述羅裏羅嗦的都很是理論化，我是個開發者而不是研究者，我喜歡具體的例子。

咱們來看看 SQLite 優化器是怎麼工做的。這是個輕量化數據庫，它使用一種簡單優化器，基於帶有附加規則的貪婪算法，來限制可能性的數量。

SQLite 在有 CROSS JOIN 操做符時從不給表從新排序
使用嵌套聯接
外聯接始終按順序評估
……
3.8.0以前的版本使用『最近鄰居』貪婪算法來搜尋最佳查詢計劃
等等……咱們見過這個算法！真是巧哈！
從3.8.0版本（發佈於2015年）開始，SQLite使用『N最近鄰居』貪婪算法來搜尋最佳查詢計劃

咱們再看看另外一個優化器是怎麼工做的。IBM DB2 跟全部企業級數據庫都相似，我討論它是由於在切換到大數據以前，它是我最後真正使用的數據庫。

看過官方文檔後，咱們瞭解到 DB2 優化器可讓你使用 7 種級別的優化：

對聯接使用貪婪算法
0 – 最小優化，使用索引掃描和嵌套循環聯接，避免一些查詢重寫
- 1 – 低級優化
- 2 – 徹底優化
對聯接使用動態編程算法
3 – 中等優化和粗略的近似法
- 5 – 徹底優化，使用帶有啓發式的全部技術
- 7 – 徹底優化，相似級別5，但不用啓發式
- 9 – 最大優化，徹底不顧開銷，考慮全部可能的聯接順序，包括笛卡爾乘積

能夠看到 DB2 使用貪婪算法和動態編程算法。固然，他們不會把本身的啓發算法分享出來的，由於查詢優化器是數據庫的看家本領。

DB2 的默認級別是 5，優化器使用下列特性：【譯者注：如下出現的一些概念我沒有作考證，由於[ 這段不重要，能夠跳過 ]】

使用全部可用的統計，包括線段樹（frequent-value）和分位數統計（quantile statistics）。
使用全部查詢重寫規則（含物化查詢表路由，materialized query table routing），除了在極少狀況下適用的計算密集型規則。
使用動態編程模擬聯接
有限使用組合內關係（composite inner relation）
對於涉及查找表的星型模式，有限使用笛卡爾乘積
考慮寬泛的訪問方式，含列表預取（list prefetch，注：咱們將討論什麼是列表預取），index ANDing（注：一種對索引的特殊操做），和物化查詢表路由。

默認的，DB2 對聯接排列使用受啓發式限制的動態編程算法。

其它狀況 (GROUP BY, DISTINCT…) 由簡單規則處理。

查詢計劃緩存

因爲建立查詢計劃是耗時的，大多數據庫把計劃保存在查詢計劃緩存，來避免重複計算。這個話題比較大，由於數據庫須要知道何時更新過期的計劃。辦法是設置一個上限，若是一個表的統計變化超過了上限，關於該表的查詢計劃就從緩存中清除。

查詢執行器

在這個階段，咱們有了一個優化的執行計劃，再編譯爲可執行代碼。而後，若是有足夠資源（內存，CPU），查詢執行器就會執行它。計劃中的操做符 (JOIN, SORT BY …) 能夠順序或並行執行，這取決於執行器。爲了得到和寫入數據，查詢執行器與數據管理器交互，本文下一部分來討論數據管理器。

數據管理器

在這一步，查詢管理器執行了查詢，須要從表和索引獲取數據，因而向數據管理器提出請求。可是有 2 個問題：

關係型數據庫使用事務模型，因此，當其餘人在同一時刻使用或修改數據時，你沒法獲得這部分數據。
數據提取是數據庫中速度最慢的操做，因此數據管理器須要足夠聰明地得到數據並保存在內存緩衝區內。

在這一部分，我沒看看關係型數據庫是如何處理這兩個問題的。我不會講數據管理器是怎麼得到數據的，由於這不是最重要的（並且本文已經夠長的了！）。

緩存管理器

我已經說過，數據庫的主要瓶頸是磁盤 I/O。爲了提升性能，現代數據庫使用緩存管理器。

查詢執行器不會直接從文件系統拿數據，而是向緩存管理器要。緩存管理器有一個內存緩存區，叫作緩衝池，從內存讀取數據顯著地提高數據庫性能。對此很難給出一個數量級，由於這取決於你須要的是哪一種操做：

順序訪問（好比：全掃描） vs 隨機訪問（好比：按照row id訪問）
讀仍是寫

以及數據庫使用的磁盤類型：

7.2k/10k/15k rpm的硬盤
SSD
RAID 1/5/…

要我說，內存比磁盤要快100到10萬倍。

然而，這致使了另外一個問題（數據庫老是這樣…)，緩存管理器須要在查詢執行器使用數據以前獲得數據，不然查詢管理器不得不等待數據從緩慢的磁盤中讀出來。

預讀

這個問題叫預讀。查詢執行器知道它將須要什麼數據，由於它瞭解整個查詢流，並且經過統計也瞭解磁盤上的數據。道理是這樣的：

當查詢執行器處理它的第一批數據時
會告訴緩存管理器預先裝載第二批數據
當開始處理第二批數據時
告訴緩存管理器預先裝載第三批數據，而且告訴緩存管理器第一批能夠從緩存裏清掉了。
……

緩存管理器在緩衝池裏保存全部的這些數據。爲了肯定一條數據是否有用，緩存管理器給緩存的數據添加了額外的信息（叫閂鎖）。

有時查詢執行器不知道它須要什麼數據，有的數據庫也不提供這個功能。相反，它們使用一種推測預讀法（好比：若是查詢執行器想要數據一、三、5，它不久後極可能會要七、九、11），或者順序預讀法（這時候緩存管理器只是讀取一批數據後簡單地從磁盤加載下一批連續數據）。

爲了監控預讀的工做情況，現代數據庫引入了一個度量叫緩衝/緩存命中率，用來顯示請求的數據在緩存中找到而不是從磁盤讀取的頻率。

注：糟糕的緩存命中率不老是意味着緩存工做狀態不佳。更多信息請閱讀Oracle文檔。

緩衝只是容量有限的內存空間，所以，爲了加載新的數據，它須要移除一些數據。加載和清除緩存須要一些磁盤和網絡I/O的成本。若是你有個常常執行的查詢，那麼每次都把查詢結果加載而後清除，效率就過低了。現代數據庫用緩衝區置換策略來解決這個問題。

緩衝區置換策略

多數現代數據庫(至少 SQL Server, MySQL, Oracle 和 DB2)使用 LRU 算法。

LRU

LRU表明最近最少使用（Least Recently Used）算法，背後的原理是：在緩存裏保留的數據是最近使用的，因此更有可能再次使用。

圖解：

爲了更好的理解，我假設緩衝區裏的數據沒有被閂鎖鎖住（就是說是能夠被移除的）。在這個簡單的例子裏，緩衝區能夠保存 3 個元素：

1：緩存管理器（簡稱CM）使用數據1，把它放入空的緩衝區
2：CM使用數據4，把它放入半載的緩衝區
3：CM使用數據3，把它放入半載的緩衝區
4：CM使用數據9，緩衝區滿了，因此數據1被清除，由於它是最後一個最近使用的，數據9加入到緩衝區
5：CM使用數據4，數據4已經在緩衝區了，因此它再次成爲第一個最近使用的。
6：CM使用數據1，緩衝區滿了，因此數據9被清除，由於它是最後一個最近使用的，數據1加入到緩衝區
……

這個算法效果很好，可是有些限制。若是對一個大表執行全表掃描怎麼辦？換句話說，當表/索引的大小超出緩衝區會發生什麼？使用這個算法會清除以前緩存內全部的數據，並且全掃描的數據極可能只使用一次。

改進

爲了防止這個現象，有些數據庫增長了特殊的規則，好比Oracle文檔中的描述：

『對很是大的表來講，數據庫一般使用直接路徑來讀取，即直接加載區塊[……]，來避免填滿緩衝區。對於中等大小的表，數據庫能夠使用直接讀取或緩存讀取。若是選擇緩存讀取，數據庫把區塊置於LRU的尾部，防止清空當前緩衝區。』

還有一些可能，好比使用高級版本的LRU，叫作 LRU-K。例如，SQL Server 使用 LRU-2。

這個算法的原理是把更多的歷史記錄考慮進來。簡單LRU（也就是 LRU-1），只考慮最後一次使用的數據。LRU-K呢：

考慮數據最後第K次使用的狀況
數據使用的次數加進了權重
一批新數據加載進入緩存，舊的可是常用的數據不會被清除（由於權重更高）
可是這個算法不會保留緩存中再也不使用的數據
因此數據若是再也不使用，權重值隨着時間推移而下降

計算權重是須要成本的，因此SQL Server只是使用 K=2，這個值性能不錯並且額外開銷能夠接受。

關於LRU-K更深刻的知識，能夠閱讀早期的研究論文（1993）：數據庫磁盤緩衝的LRU-K頁面置換算法

其餘算法

固然還有其餘管理緩存的算法，好比：

2Q（類LRU-K算法）
CLOCK（類LRU-K算法）
MRU（最新使用的算法，用LRU一樣的邏輯但不一樣的規則）
LRFU（Least Recently and Frequently Used，最近最少使用最近最不經常使用）
……

寫緩衝區

我只探討了讀緩存 —— 在使用以前預先加載數據。用來保存數據、成批刷入磁盤，而不是逐條寫入數據從而形成不少單次磁盤訪問。

要記住，緩衝區保存的是頁（最小的數據單位）而不是行（邏輯上/人類習慣的觀察數據的方式）。緩衝池內的頁若是被修改了但尚未寫入磁盤，就是髒頁。有不少算法來決定寫入髒頁的最佳時機，但這個問題與事務的概念高度關聯，下面咱們就談談事務。

事務管理器

最後但一樣重要的，是事務管理器，咱們將看到這個進程是如何保證每一個查詢在本身的事務內執行的。但開始以前，咱們須要理解ACID事務的概念。

「I’m on acid」

一個ACID事務是一個工做單元，它要保證4個屬性：

原子性（Atomicity）: 事務『要麼所有完成，要麼所有取消』，即便它持續運行10個小時。若是事務崩潰，狀態回到事務以前（事務回滾）。
隔離性（Isolation）: 若是2個事務 A 和 B 同時運行，事務 A 和 B 最終的結果是相同的，無論 A 是結束於 B 以前/以後/運行期間。
持久性（Durability）: 一旦事務提交（也就是成功執行）,無論發生什麼（崩潰或者出錯），數據要保存在數據庫中。
一致性（Consistency）: 只有合法的數據（依照關係約束和函數約束）能寫入數據庫，一致性與原子性和隔離性有關。

在同一個事務內，你能夠運行多個SQL查詢來讀取、建立、更新和刪除數據。當兩個事務使用相同的數據，麻煩就來了。經典的例子是從帳戶A到帳戶B的匯款。假設有2個事務：

事務1（T1）從帳戶A取出100美圓給帳戶B
事務2（T2）從帳戶A取出50美圓給帳戶B

咱們回來看看ACID屬性：

原子性確保無論 T1 期間發生什麼（服務器崩潰、網絡中斷…），你不能出現帳戶A 取走了100美圓但沒有給帳戶B 的現象（這就是數據不一致狀態）。
隔離性確保若是 T1 和 T2 同時發生，最終A將減小150美圓，B將獲得150美圓，而不是其餘結果，好比由於 T2 部分抹除了 T1 的行爲，A減小150美圓而B只獲得50美圓（這也是不一致狀態）。
持久性確保若是 T1 剛剛提交，數據庫就發生崩潰，T1 不會消失得無影無蹤。
一致性確保錢不會在系統內生成或滅失。

[如下部分不重要，能夠跳過]

現代數據庫不會使用純粹的隔離做爲默認模式，由於它會帶來巨大的性能消耗。SQL通常定義4個隔離級別：

串行化(Serializable，SQLite默認模式）：最高級別的隔離。兩個同時發生的事務100%隔離，每一個事務有本身的『世界』。
可重複讀（Repeatable read，MySQL默認模式）：每一個事務有本身的『世界』，除了一種狀況。若是一個事務成功執行而且添加了新數據，這些數據對其餘正在執行的事務是可見的。可是若是事務成功修改了一條數據，修改結果對正在運行的事務不可見。因此，事務之間只是在新數據方面突破了隔離，對已存在的數據仍舊隔離。
舉個例子，若是事務A運行」SELECT count(1) from TABLE_X」，而後事務B在 TABLE_X 加入一條新數據並提交，當事務A再運行一次 count(1)結果不會是同樣的。
這叫幻讀（phantom read）。
讀取已提交（Read committed，Oracle、PostgreSQL、SQL Server默認模式）：可重複讀+新的隔離突破。若是事務A讀取了數據D，而後數據D被事務B修改（或刪除）並提交，事務A再次讀取數據D時數據的變化（或刪除）是可見的。
這叫不可重複讀（non-repeatable read）。
讀取未提交（Read uncommitted）：最低級別的隔離，是讀取已提交+新的隔離突破。若是事務A讀取了數據D，而後數據D被事務B修改（但並未提交，事務B仍在運行中），事務A再次讀取數據D時，數據修改是可見的。若是事務B回滾，那麼事務A第二次讀取的數據D是無心義的，由於那是事務B所作的從未發生的修改（已經回滾了嘛）。
這叫髒讀（dirty read）。

多數數據庫添加了自定義的隔離級別（好比 PostgreSQL、Oracle、SQL Server的快照隔離），並且並無實現SQL規範裏的全部級別（尤爲是讀取未提交級別）。

默認的隔離級別能夠由用戶/開發者在創建鏈接時覆蓋（只須要增長很簡單的一行代碼）。

併發控制

確保隔離性、一致性和原子性的真正問題是對相同數據的寫操做（增、更、刪）：

若是全部事務只是讀取數據，它們能夠同時工做，不會更改另外一個事務的行爲。
若是（至少）有一個事務在修改其餘事務讀取的數據，數據庫須要找個辦法對其它事務隱藏這種修改。並且，它還須要確保這個修改操做不會被另外一個看不到這些數據修改的事務擦除。

這個問題叫併發控制。

最簡單的解決辦法是依次執行每一個事務（即順序執行），但這樣就徹底沒有伸縮性了，在一個多處理器/多核服務器上只有一個核心在工做，效率很低。

理想的辦法是，每次一個事務建立或取消時：

監控全部事務的全部操做
檢查是否2個（或更多）事務的部分操做由於讀取/修改相同的數據而存在衝突
從新編排衝突事務中的操做來減小衝突的部分
按照必定的順序執行衝突的部分（同時非衝突事務仍然在併發運行）
考慮事務有可能被取消

用更正規的說法，這是對衝突的調度問題。更具體點兒說，這是個很是困難並且CPU開銷很大的優化問題。企業級數據庫沒法承擔等待幾個小時，來尋找每一個新事務活動最好的調度，所以就使用不那麼理想的方式以免更多的時間浪費在解決衝突上。

鎖管理器

爲了解決這個問題，多數數據庫使用鎖和/或數據版本控制。這是個很大的話題，我會集中探討鎖，和一點點數據版本控制。

悲觀鎖

原理是：

若是一個事務須要一條數據
它就把數據鎖住
若是另外一個事務也須要這條數據
它就必需要等第一個事務釋放這條數據
這個鎖叫排他鎖。

可是對一個僅僅讀取數據的事務使用排他鎖很是昂貴，由於這會迫使其它只須要讀取相同數據的事務等待。所以就有了另外一種鎖，共享鎖。

共享鎖是這樣的：

若是一個事務只須要讀取數據A
它會給數據A加上『共享鎖』並讀取
若是第二個事務也須要僅僅讀取數據A
它會給數據A加上『共享鎖』並讀取
若是第三個事務須要修改數據A
它會給數據A加上『排他鎖』，可是必須等待另外兩個事務釋放它們的共享鎖。

一樣的，若是一塊數據被加上排他鎖，一個只須要讀取該數據的事務必須等待排他鎖釋放才能給該數據加上共享鎖。

鎖管理器是添加和釋放鎖的進程，在內部用一個哈希表保存鎖信息（關鍵字是被鎖的數據），而且瞭解每一塊數據是：

被哪一個事務加的鎖
哪一個事務在等待數據解鎖

死鎖

可是使用鎖會致使一種狀況，2個事務永遠在等待一塊數據：

在本圖中：

事務A 給數據1 加上排他鎖而且等待獲取數據2
事務B 給數據2 加上排他鎖而且等待獲取數據1

這叫死鎖。

在死鎖發生時，鎖管理器要選擇取消（回滾）一個事務，以便消除死鎖。這但是個艱難的決定：

殺死數據修改量最少的事務（這樣能減小回滾的成本）？
殺死持續時間最短的事務，由於其它事務的用戶等的時間更長？
殺死能用更少時間結束的事務（避免可能的資源饑荒）？
一旦發生回滾，有多少事務會受到回滾的影響？

在做出選擇以前，鎖管理器須要檢查是否有死鎖存在。

哈希表能夠看做是個圖表（見上文圖），圖中出現循環就說明有死鎖。因爲檢查循環是昂貴的（全部鎖組成的圖表是很龐大的），常常會經過簡單的途徑解決：使用超時設定。若是一個鎖在超時時間內沒有加上，那事務就進入死鎖狀態。

鎖管理器也能夠在加鎖以前檢查該鎖會不會變成死鎖，可是想要完美的作到這一點仍是很昂貴的。所以這些預檢常常設置一些基本規則。

兩段鎖

實現純粹的隔離最簡單的方法是：事務開始時獲取鎖，結束時釋放鎖。就是說，事務開始前必須等待確保本身能加上全部的鎖，當事務結束時釋放本身持有的鎖。這是行得通的，可是爲了等待全部的鎖，大量的時間被浪費了。

更快的方法是兩段鎖協議（Two-Phase Locking Protocol，由 DB2 和 SQL Server使用），在這裏，事務分爲兩個階段：

成長階段：事務能夠得到鎖，但不能釋放鎖。
收縮階段：事務能夠釋放鎖（對於已經處理完並且不會再次處理的數據），但不能得到新鎖。

這兩條簡單規則背後的原理是：

釋放再也不使用的鎖，來下降其它事務的等待時間
防止發生這類狀況：事務最初得到的數據，在事務開始後被修改，當事務從新讀取該數據時發生不一致。

這個規則能夠很好地工做，但有個例外：若是修改了一條數據、釋放了關聯的鎖後，事務被取消（回滾），而另外一個事務讀到了修改後的值，但最後這個值卻被回滾。爲了不這個問題，全部獨佔鎖必須在事務結束時釋放。

多說幾句

固然了，真實的數據庫使用更復雜的系統，涉及到更多類型的鎖（好比意向鎖，intention locks）和更多的粒度（行級鎖、頁級鎖、分區鎖、表鎖、表空間鎖），可是道理是相同的。

我只探討純粹基於鎖的方法，數據版本控制是解決這個問題的另外一個方法。

版本控制是這樣的：

每一個事務能夠在相同時刻修改相同的數據
每一個事務有本身的數據拷貝（或者叫版本）
若是2個事務修改相同的數據，只接受一個修改，另外一個將被拒絕，相關的事務回滾（或從新運行）

這將提升性能，由於：

讀事務不會阻塞寫事務
寫事務不會阻塞讀
沒有『臃腫緩慢』的鎖管理器帶來的額外開銷

除了兩個事務寫相同數據的時候，數據版本控制各個方面都比鎖表現得更好。只不過，你很快就會發現磁盤空間消耗巨大。

數據版本控制和鎖機制是兩種不一樣的看法：樂觀鎖和悲觀鎖。二者各有利弊，徹底取決於使用場景（讀多仍是寫多）。關於數據版本控制，我推薦這篇很是優秀的文章，講的是PostgreSQL如何實現多版本併發控制的。

一些數據庫，好比DB2（直到版本 9.7）和 SQL Server（不含快照隔離）僅使用鎖機制。其餘的像PostgreSQL, MySQL 和 Oracle 使用鎖和鼠標版本控制混合機制。我不知道是否有僅用版本控制的數據庫（若是你知道請告訴我）。

[2015-08-20更新]一名讀者告訴我：

Firebird 和 Interbase 用不帶鎖的版本控制。

版本控制對索引的影響挺有趣的：有時惟一索引會出現重複，索引的條目會多於錶行數，等等。

若是你讀過不一樣級別的隔離那部份內容，你會知道，提升隔離級別就會增長鎖的數量和事務等待加鎖的時間。這就是爲何多數數據庫默認不會使用最高級別的隔離（即串行化）。

固然，你老是能夠本身去主流數據庫（像MySQL, PostgreSQL 或 Oracle）的文檔裏查一下。

日誌管理器

咱們已經知道，爲了提高性能，數據庫把數據保存在內存緩衝區內。但若是當事務提交時服務器崩潰，崩潰時還在內存裏的數據會丟失，這破壞了事務的持久性。

你能夠把全部數據都寫在磁盤上，可是若是服務器崩潰，最終數據可能只有部分寫入磁盤，這破壞了事務的原子性。

事務做出的任何修改必須是或者撤銷，或者完成。

有 2 個辦法解決這個問題：

影子副本/頁（Shadow copies/pages）：每一個事務建立本身的數據庫副本（或部分數據庫的副本），並基於這個副原本工做。一旦出錯，這個副本就被移除；一旦成功，數據庫當即使用文件系統的一個把戲，把副本替換到數據中，而後刪掉『舊』數據。
事務日誌（Transaction log）：事務日誌是一個存儲空間，在每次寫盤以前，數據庫在事務日誌中寫入一些信息，這樣當事務崩潰或回滾，數據庫知道如何移除或完成還沒有完成的事務。

WAL（預寫式日誌）

影子副本/頁在運行較多事務的大型數據庫時製造了大量磁盤開銷，因此現代數據庫使用事務日誌。事務日誌必須保存在穩定的存儲上，我不會深挖存儲技術，但至少RAID磁盤是必須的，以防磁盤故障。

多數數據庫（至少是Oracle, SQL Server, DB2, PostgreSQL, MySQL 和 SQLite) 使用預寫日誌協議（Write-Ahead Logging protocol ，WAL）來處理事務日誌。WAL協議有 3 個規則：

1) 每一個對數據庫的修改都產生一條日誌記錄，在數據寫入磁盤以前日誌記錄必須寫入事務日誌。
2) 日誌記錄必須按順序寫入；記錄 A 發生在記錄 B 以前，則 A 必須寫在 B 以前。
3) 當一個事務提交時，在事務成功以前，提交順序必須寫入到事務日誌。

這個工做由日誌管理器完成。簡單的理解就是，日誌管理器處於緩存管理器（cache manager）和數據訪問管理器（data access manager，負責把數據寫入磁盤）之間，每一個 update / delete / create / commit / rollback 操做在寫入磁盤以前先寫入事務日誌。簡單，對吧？

回答錯誤！咱們研究了這麼多內容，如今你應該知道與數據庫相關的每一件事都帶着『數據庫效應』的詛咒。好吧，咱們說正經的，問題在於，如何找到寫日誌的同時保持良好的性能的方法。若是事務日誌寫得太慢，總體都會慢下來。

ARIES

1992年，IBM 研究人員『發明』了WAL的加強版，叫 ARIES。ARIES 或多或少地在現代數據庫中使用，邏輯未必相同，但AIRES背後的概念無處不在。我給發明加了引號是由於，按照MIT這門課的說法，IBM 的研究人員『僅僅是寫了事務恢復的最佳實踐方法』。AIRES 論文發表的時候我才 5 歲，我不關心那些酸溜溜的科研人員老掉牙的閒言碎語。事實上，我說起這個典故，是在開始探討最後一個技術點前讓你輕鬆一下。我閱讀過這篇 ARIES 論文的大量篇幅，發現它頗有趣。在這一部分我只是簡要的談一下 ARIES，不過我強烈建議，若是你想了解真正的知識，就去讀那篇論文。

ARIES 表明『數據庫恢復原型算法』（Algorithms for Recovery and Isolation Exploiting Semantics）。

這個技術要達到一個雙重目標：

1) 寫日誌的同時保持良好性能
2) 快速和可靠的數據恢復

有多個緣由讓數據庫不得不回滾事務：

由於用戶取消
由於服務器或網絡故障
由於事務破壞了數據庫完整性（好比一個列有惟一性約束而事務添加了重複值）
由於死鎖

有時候（好比網絡出現故障），數據庫能夠恢復事務。

這怎麼可能呢？爲了回答這個問題，咱們須要瞭解日誌裏保存的信息。

日誌

事務的每個操做（增/刪/改）產生一條日誌，由以下內容組成：

LSN：一個惟一的日誌序列號（Log Sequence Number）。LSN是按時間順序分配的 * ，這意味着若是操做 A 先於操做 B，log A 的 LSN 要比 log B 的 LSN 小。
TransID：產生操做的事務ID。
PageID：被修改的數據在磁盤上的位置。磁盤數據的最小單位是頁，因此數據的位置就是它所處頁的位置。
PrevLSN：同一個事務產生的上一條日誌記錄的連接。
UNDO：取消本次操做的方法。
好比，若是操做是一次更新，UNDO將或者保存元素更新前的值/狀態（物理UNDO），或者回到原來狀態的反向操做（邏輯UNDO） **。
REDO：重複本次操做的方法。一樣的，有 2 種方法：或者保存操做後的元素值/狀態，或者保存操做自己以便重複。
…：（供您參考，一個 ARIES 日誌還有 2 個字段：UndoNxtLSN 和 Type）。

進一步說，磁盤上每一個頁（保存數據的，不是保存日誌的）都記錄着最後一個修改該數據操做的LSN。

*LSN的分配其實更復雜，由於它關係到日誌存儲的方式。但道理是相同的。

** ARIES 只使用邏輯UNDO，由於處理物理UNDO太過混亂了。

注：據我所知，只有 PostgreSQL 沒有使用UNDO，而是用一個垃圾回收服務來刪除舊版本的數據。這個跟 PostgreSQL 對數據版本控制的實現有關。

爲了更好的說明這一點，這有一個簡單的日誌記錄演示圖，是由查詢「UPDATE FROM PERSON SET AGE = 18;」產生的，咱們假設這個查詢是事務18執行的。【譯者注： SQL 語句原文如此，應該是做者筆誤】

每條日誌都有一個惟一的LSN，連接在一塊兒的日誌屬於同一個事務。日誌按照時間順序連接（連接列表的最後一條日誌是最後一個操做產生的）。

日誌緩衝區

爲了防止寫日誌成爲主要的瓶頸，數據庫使用了日誌緩衝區。

當查詢執行器要求作一次修改：

1) 緩存管理器將修改存入本身的緩衝區；
2) 日誌管理器將相關的日誌存入本身的緩衝區；
3) 到了這一步，查詢執行器認爲操做完成了（所以能夠請求作另外一次修改）；
4) 接着（不久之後）日誌管理器把日誌寫入事務日誌，何時寫日誌由某算法來決定。
5) 接着（不久之後）緩存管理器把修改寫入磁盤，何時寫盤由某算法來決定。

當事務提交，意味着事務每個操做的 1 2 3 4 5 步驟都完成了。寫事務日誌是很快的，由於它只是『在事務日誌某處增長一條日誌』；而數據寫盤就更復雜了，由於要用『可以快速讀取的方式寫入數據』。

STEAL 和 FORCE 策略

出於性能方面的緣由，第 5 步有可能在提交以後完成，由於一旦發生崩潰，還有可能用REDO日誌恢復事務。這叫作 NO-FORCE策略。

數據庫能夠選擇FORCE策略（好比第 5 步在提交以前必須完成）來下降恢復時的負載。

另外一個問題是，要選擇數據是一步步的寫入（STEAL策略），仍是緩衝管理器須要等待提交命令來一次性所有寫入（NO-STEAL策略）。選擇STEAL仍是NO-STEAL取決於你想要什麼：快速寫入可是從 UNDO 日誌恢復緩慢，仍是快速恢復。

總結一下這些策略對恢復的影響：

STEAL/NO-FORCE 須要 UNDO 和 REDO: 性能高，可是日誌和恢復過程更復雜 (好比 ARIES)。多數數據庫選擇這個策略。注：這是我從多個學術論文和教程裏看到的，但並無看到官方文檔裏顯式說明這一點。
STEAL/ FORCE 只須要 UNDO.
NO-STEAL/NO-FORCE 只須要 REDO.
NO-STEAL/FORCE 什麼也不須要: 性能最差，並且須要巨大的內存。