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

1.     此提交含有trunk標(biāo)簽。
2.     此提交有個(gè)子提交含有“trunk標(biāo)簽。
3.     此提交有個(gè)父提交含有“trunk標(biāo)簽。

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

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

•     查找提交$ckid的所有子提交，然后對(duì)每一個(gè)進(jìn)行測(cè)試，看看是否有子提交包含$trunk標(biāo)簽
•     查找所有包含$trunk標(biāo)簽的提交，然后對(duì)每個(gè)這樣的提交進(jìn)行測(cè)試，看看是否有$ckid提交的子提交。

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

出現(xiàn)這樣的問(wèn)題是因?yàn)樗饕⒉皇蔷哂型荣|(zhì)量。一個(gè)提交有可能只有一個(gè)子提交。這樣plink_i1索引的第一個(gè)字段通?？s減值對(duì)一行進(jìn)行搜索。不過(guò)由于成千上萬(wàn)的提交都包含有trunk標(biāo)簽，所以tagxref_i1的第一個(gè)字段對(duì)縮減搜索不會(huì)有多大幫助。

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

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

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

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

4.2 問(wèn)題修正

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

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

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

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

    創(chuàng)建正確的索引。大多數(shù)sql性能問(wèn)題不是因?yàn)椴樵円?guī)劃器問(wèn)題而引起的，而是因?yàn)槿鄙俸线m的索引。確保索引可以促進(jìn)所有大型的查詢。大多數(shù)性能問(wèn)題都可以使用一個(gè)或者兩個(gè)create index命令來(lái)解決，而不需要對(duì)應(yīng)用代碼進(jìn)行修改。

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

    這篇文章的前一段所說(shuō)的fossil性能問(wèn)題是因?yàn)閠agxref表的tagxref_i1索引的最左一子段(tagid字段）具有相同值得項(xiàng)超過(guò)1萬(wàn)。

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

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

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

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

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

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

    使用indexed by語(yǔ)法，強(qiáng)制有問(wèn)題的查詢選擇特定的索引。同前兩個(gè)標(biāo)題一樣，如果可能的話，盡量避免使用這個(gè)方法，尤其避免在開發(fā)的早期這么做，因?yàn)楹芮宄?，它是一個(gè)不成熟的優(yōu)化措施。
6.0 結(jié)論

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