段背后也必须有智慧：我们必须尽量扫描数据返回比例最高的表、索引，或者这两者的分区；

    扫描时的过滤条件必须是粗粒度的，从而返回的数据量比较大，使扫描更有价值；扫描显然违

    背了“尽快去除不必要数据”这一原则，但一旦扫描结束应立即重新贯彻该原则。

    相反，采取扫描方式不合适的情况下，应尽量减少要访问数据的块数。为此，最常用的手段就

    是使用索引（而不是表），尽管所有索引的总数据量经常比表还大，但单个索引则远比表要小。

    如果索引包含了所有需要的信息，则扫描索引而不扫描表是相当合理的，可以利用诸如聚集索

    引等避免访问表的技术。

    无论是要返回大量记录，还是要对大量记录进行检查，每条记录的处理都需小心。例如，一个

    xìng能不佳的用户自定义函数的调用，如果发生在“返回小结果集的select 列表”中或在“可选择xìng

    很高的where 子句”中，则影响不大；但返回大数据集的查询可能会调用这个函数几十万次，

    DBMS服务器就不堪重负了，这时必须优化代码。

    还要重点关注子查询的使用。处理大量记录时，关联子查询（Correlated subquery）是xìng能杀手。

    当一个查询包含多个子查询时，必须让它们cāo作各不相同、自给自足的数据子集，以避免子查

    询相互依赖；到查询执行的最后阶段，多个子查询分别得到的不同数据集经过哈希连接或集合

    cāo作得到结果集。

    查询执行的并行化（parallelism）也是个好主意，不过只应在“并发活动会话数（concurrently active

    sessions）”很少（典型情况为批处理cāo作）时才这么做。并行化是由DBMS 实现的，如果有可

    能，DBMS把一个查询分割为多个并行运行的子任务，并由另一个专门的任务来协调。并发用

    户数很大时，并行化反而会影响处理能力。一般而言，并发用户数又多、要处理的信息量又大

    的情况下，最好做好战斗准备，因为这经常靠投入更多硬件来解决。

    除了处理过程中由资源争用引起的等待之外，查询必须访问的数据量是影响“响应时间”的主要

    因素。但正如第4章讲过的，最终用户并不关心客观的数据量分析，他们只关心查询获得的数据。

    基于一个表的自连接

    Self-Joins on One Table

    利用卓越的、广为流行的范式（注2），有助于我们设计正确的关系数据库（至少满足3NF）。所

    有非键字段均与键相关、并完整依赖于键，非键字段之间没有任何依赖。每条记录具有逻辑一

    致xìng，同一个表中没有重复记录。于是，才能够建立同一个表之间的连接关系：使用同一查询

    从同一表中选择不同记录的集合（可以相jiāo），然后连接它们，就好像它们来自不同表一样。本

    节将讨论简单的自连接。本节不讨论较复杂的嵌套层次结构，这一主题在第7章中讨论。

    自连接，指表与自身的连接，这种情况比分层查询更常见。自连接用于“从不同角度看

    待相同数据”的情况，例如，查询航班会两次用到airports 表，一次找到“出发机场”的名称，另

    一次找出“到达机场”的名称：

    select f.flight_number