b_q

    where sub_q.ordid = orders.ordid

    and

    这第二个方法对索引的要求有所不同：如果商品数量不超过数百万项，即使artncom字段上没有

    索引，基于商品名称条件的查询xìng能也不错。表orderdetail的artid字段可能也不需索引：如果商

    品很畅销，出现在许多订单中，则表orderdetail和articles之间的连接通过哈希或合并连接comrge

    join）更高效，而artid字段上的索引会引起嵌套的循环。与第一种方法相比，第二种方法属于索

    引较少的解决方案。一方面，我们无法承受为表的每个字段建立索引；另一方面，应用中都有

    一些“次要的”查询，它们不太重要，对响应时间要求也不苛刻，索引较少的解决方案完全满足

    它们的要求。

    总结：为现存的查询增加搜索条件，可能彻底改变先前的构想：修改过的查询成了新查询。

    多个间接宽泛条件的jiāo集

    Small Intersection, Indirect Broad Criteria

    为了构造查询条件，需要连接（join）源表之外的表，并在条件中使用该表的字段，就叫间接条

    件（indirect criterion）。正如上一节“多个宽泛条件的jiāo集”的情况，通过两个或多个宽泛条件的

    jiāo集处理获取小结果集，是项艰难的工作；若是涉及多次joincāo作，或者对中心表（central table）

    进行joincāo作，则会更加困难——这是典型的“星形schema（star schema）”（第10章详细讨论），

    实际的数据库系统中经常遇到。对于多个可选择xìng差的条件，一些罕见的组合要求我们预测哪

    些地方会执行完整扫描。当牵涉到多个表时，这种情况颇值得研究。

    DBMS引擎的执行始于一个表、一个索引或一个分区，就算DBMS引擎能并行处理数据也是如

    此。虽然由多个大型数据集合的jiāo集所定义的结果集非常小，但前期的全表扫描、两次扫描等

    问题依然存在，还可能在结果上执行嵌套循环（nested loop）、哈希连接

    （hash join）或合并连接comrge join）。此时，困难在于确定结果集的哪种表组合产生的记录数

    最少。这就好比，找到防线最弱的环节，然后利用它获得最终结果。

    下面通过一个实际的Oracle 案例说明这种情况。原始查询相当复杂，有两个表在from 子句中

    都出现了两次，虽然表本身不太庞大（大的包含700 000 行数据），但传递给查询的九个参数可

    选择xìng都太差：

    select (data from ttex_a,

    ttex_b,

    ttraoma,

    topeoma,

    ttypobj,

    ttrcap_a,

    ttrcap_b,

    trgppdt,

    tstg_a)

    from ttrcapp ttrcap_a,

    ttrcapp ttrcap_b,

    tstg tstg_a,

    topeoma,

    ttra