這個查詢不是特別復(fù)雜，不過，即便這樣，它仍然可以替代上百行，也許是上千行處理過程代碼。這個查詢的要點是：向下掃描event表，查找滿足下列三個條件中任何一個的最新的200條提交記錄：

1.     此提交含有trunk標簽。
2.     此提交有個子提交含有“trunk標簽。
3.     此提交有個父提交含有“trunk標簽。

第一個條件將顯示所有主干分支上的提交，第二個和第三個條件包含合并到主干分支，或者由主干分支產(chǎn)生的提交。這三個條件是通過在此查詢的where子句中用or連接三個exists語句實現(xiàn)的。使用下一代查詢規(guī)劃器引起的性能下降是由第二個和第三個條件產(chǎn)生的。兩個條件里存在的問題是相同的，因此我們只看第二個條件。第二個條件的子查詢可以重寫為如下語句（把次要的和不重要的進行了簡化）：

plink表保存著各個提交之間的父子關(guān)系。tagxref表把標簽映射到提交上。作為參考，對這兩個表進行查詢的模式的相關(guān)部分顯示如下：
實現(xiàn)這樣的查詢只有兩個方法值得考慮。（當(dāng)然可能還有許多其他算法，不過它們中的任何一個都不是“最佳”算法的競爭者。

•     查找提交$ckid的所有子提交，然后對每一個進行測試，看看是否有子提交包含$trunk標簽
•     查找所有包含$trunk標簽的提交，然后對每個這樣的提交進行測試，看看是否有$ckid提交的子提交。

僅憑直覺，我們?nèi)祟愓J為第一個算法是最佳選擇。每個提交可能有幾個子提交（其中有一個提交是我們最常用到的。），然后對每個子提交進行測試，用對數(shù)運算計算出查找到$trunk標簽的時間。實際上，算法1確實較快。然而下一代查詢規(guī)劃器卻沒有使用人們直覺上的最佳選擇。下一代查詢規(guī)劃器一定是選擇了很難得算法，算法2在數(shù)學(xué)上相對稍微難些。這是因為：在沒有其他信息的情況下下一代查詢規(guī)劃器一定假設(shè)plink_i1和tagxref_i1索引具有同等的質(zhì)量和同等的可選擇性。算法2使用了tagxref_i1索引的一個字段，plink_i1索引的兩個字段，而算法1只是使用了這兩個索引的第一個字段。正是由于算法2使用了多個字段的索引，所以下一代查詢規(guī)劃器才會以自己的標準正確地確定它作為兩種算法中性能較好的算法。兩個算法所花費的時間非常接近，算法2 只是勉強稍稍領(lǐng)先算法1。不過，這種情況下，選擇算法2確實是正確的。
很不幸，在實際的應(yīng)用中算法2比算法1要慢些。

出現(xiàn)這樣的問題是因為索引并不是具有同等質(zhì)量。一個提交有可能只有一個子提交。這樣plink_i1索引的第一個字段通常縮減值對一行進行搜索。不過由于成千上萬的提交都包含有trunk標簽，所以tagxref_i1的第一個字段對縮減搜索不會有多大幫助。

下一代查詢規(guī)劃器是沒有辦法知道tagxref_i1在這樣的查詢中幾乎沒有什么用處，除非在數(shù)據(jù)庫上運行analyze。analyze命令 收集了各個索引的質(zhì)量統(tǒng)計信息，并把 這些統(tǒng)計信息存儲到sqlite_stat1表里。如果下一代查詢規(guī)劃器能夠訪問這些統(tǒng)計信息 ，那么在很大程度上它就會非常容易地選擇算法1作為最佳算法。
難道舊查詢規(guī)劃器沒有選擇算法2？很簡單：因為nn算法甚至從來都沒有考慮到算法2。這類規(guī)劃問題的圖示如下：

在如左圖那樣“沒有運行analyze“的情況下，nn算法選擇循環(huán)p9plink)作為外循環(huán)，因為4.9比5.2要小，結(jié)果就是選擇p-t路徑，即算法1。nn算法只是在每一步查找一個最佳選擇路徑，因此它完全忽略了這樣一個事實：5.2+4.4是比4.9+4.8性能稍稍有些好的規(guī)劃。然而n3算法對著兩個連接追蹤了5個最佳路徑，因此它最終選擇了t-p路徑，因為這條路徑的總體資源消耗要少一些。路徑t-p就是算法2。

注意： 如果運行了analyze，那么對資源消耗的評估就更加接近于現(xiàn)實，這樣nn和n3都選擇算法1。

（附注：最新的兩圖中對資源消耗的評估是下一代查詢規(guī)劃器使用以2為底的對數(shù)算法計算得出來的，而且與舊查詢規(guī)劃器相比假設(shè)的資源消耗稍微有些不同。因此，最后兩個圖中的資源消耗評估不能與tpc-h q8圖里的資源消耗評估進行比較。）

4.2 問題修正

對資源倉庫數(shù)據(jù)庫運行analyze可立即修復(fù)這類性能問題。然而，無論是否對資源倉庫是否進行分析，我們都要求fossil十分強壯，而且總是能夠快速地運行?；谶@個原因，我們修改查詢使用cross join操作符而不使用常用的join操作符。sqlite將不會對cross join連接的表重新排序。這個功能是sqlite中長期都有的一個功能，做這么特別的設(shè)計就是允許具有豐富經(jīng)驗的開發(fā)人員能夠強制sqlite執(zhí)行特定的嵌套循環(huán)順序。一旦某個連接更改為（增加了一個關(guān)鍵字的）cross join這樣的連接，下一代查詢規(guī)劃器就不管是否使用analyze收集統(tǒng)計統(tǒng)計信息都強制選擇稍稍快一點的算法1。

我們說算法1快一些“，不過，嚴格來說這么說不準確。對一個常見的存儲倉庫運行算法1是快一些，不過，可能構(gòu)建這樣一種資源倉庫：對資源倉庫的每一次提交都是提交給不同的名字唯一的分支上，而且所有的提交都是根提交的子提交。這種情況下，tagxref_i1與plink_i1相比就具有更多的可選項了，此時算法2才真正快一些。然而實際中這樣的資源倉庫極不可能出現(xiàn)，所以使用cross join語法硬編碼嵌套循環(huán)的順序是解決這種情形下存在問題的適合方案。

5.0 避免或者修正查詢規(guī)劃器問題的方法一覽表

    不要驚慌！查詢規(guī)劃器選擇差的規(guī)劃這種情況實際上是非常罕見的。你未必會在應(yīng)用中碰到這樣的問題。如果你沒有性能方面問題，那么你就不必為此而擔(dān)心。

    創(chuàng)建正確的索引。大多數(shù)sql性能問題不是因為查詢規(guī)劃器問題而引起的，而是因為缺少合適的索引。確保索引可以促進所有大型的查詢。大多數(shù)性能問題都可以使用一個或者兩個create index命令來解決，而不需要對應(yīng)用代碼進行修改。

    避免創(chuàng)建低質(zhì)量的索引。（用于解決查詢規(guī)劃器問題而創(chuàng)建的）低質(zhì)量索引是這樣的索引：表里的索引最左一個字段具有相同值的行超過10行或者20行。特別注意，避免使用布爾字段或或者“枚舉類型”字段作為索引的最左一字段。

    這篇文章的前一段所說的fossil性能問題是因為tagxref表的tagxref_i1索引的最左一子段(tagid字段）具有相同值得項超過1萬。

    如果你一定要使用低質(zhì)量的索引，那么請一定要運行analyze。只要查詢規(guī)劃器知道那個索引時低質(zhì)量的，那么低質(zhì)量的索引就不會讓它迷惑。查詢規(guī)劃器知曉低質(zhì)量索引的方法是通過sqlite_stat1表的內(nèi)容來實現(xiàn)的，這個表示有analyze命令計算得來的。

    當(dāng)然，analyze只有在數(shù)據(jù)庫一開始就擁有非常大量的內(nèi)容的情況下才能夠高效地運行。當(dāng)你希望創(chuàng)建一個數(shù)據(jù)庫并累積了大量數(shù)據(jù)的時候，你可以運行命令analyze sqlite_master創(chuàng)建sqlite_stat1表，然后（使用常用的insert語句）向sqlite_stat1表中填入用來說明這樣的數(shù)據(jù)庫正適合你的應(yīng)用的內(nèi)容-也許這樣的內(nèi)容是你在對實驗室的某個填寫的非常完美的模板數(shù)據(jù)庫運行analyze命令后所獲得的。

    編寫你自己的代碼。增加可以讓你快速且非常容易就能知道哪些查詢需要很多時間，這樣就只運行哪些特別不需要花太長時間的查詢。

    如果查詢可能使用沒有運行分析的數(shù)據(jù)庫上的低質(zhì)量索引，那么請使用cross join語法，強制使用特定的嵌套循環(huán)順序。sqlite對cross join操作符進行特殊的處理，它強制左表為右表的外部循環(huán)。

    如果有其他方法實現(xiàn)，那么就避免這么做，因為它與任何一個sql語言理念里的強大的優(yōu)點相抵觸，特別是應(yīng)用開發(fā)人不需要了解查詢規(guī)劃。如果你使用了cross join，那么直到開發(fā)周期的后期你也要這么做，而且要在注釋里仔細地說明cross join是如何使用的，這樣以后才有可能把它去掉。在開發(fā)周期的早期就避免使用cross join,因為這么做是不成熟的優(yōu)化措施，也就是眾所周知的萬惡之源。

    使用單目運算符+,取消where子句某些限制條件。當(dāng)對某個具體的查詢有更高質(zhì)量的索引可以使用的時候，如果查詢規(guī)劃器仍然堅持選擇差質(zhì)量的索引，那么請在where子句中謹慎地使用單目運算符+,這樣做就可以強制查詢規(guī)劃器不使用差質(zhì)量的索引。如果可能的話，就盡量小心地添加這個這個運算符，而且尤其避免在應(yīng)用開發(fā)的周期的早期就使用。特別要注意：給一個與類型密切相關(guān)的等號表達式增加單目運算符+可能更改這個表達式的結(jié)果。

    使用indexed by語法，強制有問題的查詢選擇特定的索引。同前兩個標題一樣，如果可能的話，盡量避免使用這個方法，尤其避免在開發(fā)的早期這么做，因為很清楚，它是一個不成熟的優(yōu)化措施。
6.0 結(jié)論

sqlite的查詢規(guī)劃器做這樣的工作做得非常好：為正在運行的sql語句選擇快速算法。對舊查詢規(guī)劃器來說，這是事實，對新的下一代查詢規(guī)劃器來說更是這樣。也許偶然會出現(xiàn)這樣的情況：由于信息不完整，查詢規(guī)劃器選擇了稍差的查詢規(guī)劃。 與使用舊查詢規(guī)劃器相比，使用下一代查詢規(guī)劃器這種情形就會更少出現(xiàn)了，不過仍然有可能出現(xiàn)。即便出現(xiàn)了這種極少出現(xiàn)的情況，應(yīng)用開發(fā)人員需要做的是了解和幫助查詢規(guī)劃器做正確的事情。通常情況下，下一代查詢規(guī)劃器只是對sqlite做了一個新的增強，這種增強可以讓應(yīng)用運行的更快些，而且不需要開發(fā)人員做更多的思考或者動作。