能会先做连接，再作过滤，这时在连接

    中指定过滤条件利于提高xìng能，例如：

    即使过滤条件与连接（join）无关，优化器也会受到过滤条件的影响。例如，若orderdetail的主

    键为（ordid, artid），即ordid为索引的第一个属xìng，那么我们可以利用索引找到与订单相关的记

    录，就和第3章中讲的一样。但如果主键是（artid, ordid）就太不幸了（注意，就关系理论而言，

    无论哪个版本都是完全一样），此时的访问效率比（ordid, artid）作为索引时要差，甚至一些数

    据库产品无法使用该索引（注3），唯一的希望就是在ordid 上加独立索引了。

    连接了表orderdetail和orders之后，来看articles表，这不会有问题，因为表orderdetail 主键

    包括artid字段。最后，检查articles 中的值是否为Batmobile。查询就这样结束了吗？未必结

    束，因为用了distinct ，通过层层筛选的客户名还必须要排序，以剔除重复项目。

    分析至此，可以看出这个查询有多种编写方式。下面的语句采用了古老的join语法：

    本xìng难移，我偏爱这种较古老的方式。原因只有一个：从逻辑的角度来看，旧方法突显出数据

    处理顺序无足轻重这一事实；无论以什么顺序查询表，返回结果都是一样的。custcomrs 表非

    常重要，因为最终所需数据都来自该表，在此例中，其他表只起辅助作用。注意，没有适用于

    join articles a

    on a.artid = od.artid

    where c.city = 'GOTHAM'

    and a.artncom = 'BATMOBILE'

    and o.ordered >= scomfunc

    join orders o

    on o.custid = c.custid

    and a.ordered >= scomfunc

    select distinct c.custncom

    from custcomrs c,

    orders o,

    orderdetail od,

    articles a

    where c.city = 'GOTHAM'

    and c.custid = o.custid

    and o.ordid = od.ordid

    and od.artid = a.artid

    and a.artncom = 'BATMOBILE'

    and o.ordered >= scomfunc

    所有问题的解决方案，表连接的方式会因情况不同而异，而决定连接方式取决于待处理数据的

    特点。

    特定的SQL查询解决特定的问题，而未必适用于另一些问题。这就像yào，它能治好这个病人，

    却能将另一个病人医死。

    蝙蝠车买主的进一步讨论

    下面看看查询蝙蝠车买家的其他方法。我认为，避免在最高层使用distinct应该是一条基本规则。

    原因在于，即使我们遗漏了连接的某个条件，distinct也会使查询