详解sqlite中的查询规划器.pdf

这个查询不是特别复杂，不过， 即便这样， 它仍然可以替代上百行， 也许是上千行处理 过程代码。这个查询的要点是：向下扫描 event 表，查找满足下列三个条件中任何一个的最 新的 200 条提交记录： nbsp;nbsp;nbsp; 此提交含有 trunk 标签。nbsp;nbsp;nbsp; 此 提交有个子提交含有 ldquo;trunk 标签。 nbsp;nbsp;nbsp; 此提交有个父提交含有 ldquo;trunk 标签。 第一个条件将显示所有主干分支上的提交，第二个和第三个条件包含合并到主干分支， 或者由主干分支产生的提交。这三个条件是通过在此查询的 where 子句中用 or 连接三个 exists 语句实现的。 使用下一代查询规划器引起的性能下降是由第二个和第三个条件产生的。 两个条件里存在的问题是相同的， 因此我们只看第二个条件。 第二个条件的子查询可以重写 为如下语句（把次要的和不重要的进行了简化） ： plink 表保存着各个提交之间的父子关系。 tagxref 表把标签映射到提交上。作为参考， 对这两个表进行查询的模式的相关部分显示如下： 实现这样的查询只有两个方法值得考虑。 （当然可能还有许多其他算法，不过它们中的 任何一个都不是 ldquo; 最佳 rdquo; 算法的竞争者。 nbsp;nbsp;nbsp; 查找提交 $ckid 的 所有子提交， 然后对每一个进行测试， 看看是否有子提交包含 $trunk 标签 nbsp;nbsp;nbsp; 查找所有包含 $trunk 标签的提交，然后对每个这样的提交进行测试，看看是否有 $ckid 提交 的子提交。 仅凭直觉， 我们人类认为第一个算法是最佳选择。 每个提交可能有几个子提交 （其中有 一个提交是我们最常用到的。 ），然后对每个子提交进行测试，用对数运算计算出查找到 $trunk 标签的时间。实际上，算法 1 确实较快。然而下一代查询规划器却没有使用人们直觉 上的最佳选择。 下一代查询规划器一定是选择了很难得算法， 算法 2 在数学上相对稍微难些。 这是因为：在没有其他信息的情况下下一代查询规划器一定假设 plink_i1 和 tagxref_i1 索引 具有同等的质量和同等的可选择性。算法 2 使用了 tagxref_i1 索引的一个字段， plink_i1 索 引的两个字段， 而算法 1 只是使用了这两个索引的第一个字段。 正是由于算法 2 使用了多个 字段的索引， 所以下一代查询规划器才会以自己的标准正确地确定它作为两种算法中性能较 好的算法。 两个算法所花费的时间非常接近， 算法 2 只是勉强稍稍领先算法 1。不过，这种 情况下，选择算法 2 确实是正确的。 很不幸，在实际的应用中算法 2 比算法 1 要慢些。 出现这样的问题是因为索引并不是具有同等质量。 一个提交有可能只有一个子提交。 这 样 plink_i1 索引的第一个字段通常缩减值对一行进行搜索。 不过由于成千上万的提交都包含 有 trunk 标签，所以 tagxref_i1 的第一个字段对缩减搜索不会有多大帮助。 下一代查询规划器是没有办法知道 tagxref_i1 在这样的查询中几乎没有什么用处，除非 在数据库上运行 analyze。analyze 命令 收集了各个索引的质量统计信息，并把 这些统计信 息存储到 sqlite_stat1 表里。如果