按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
懂得它有双重特性。如果你只把SQL看作是一把“单刃剑”，说明你太重视具体技巧了，无法深入
理解高难度的SQL问题是如何解决的。
总结：为了取得好的优化效果，应将大部分工作安排在关系层。
优化器的有效范围
Limits of the Optimizer
优秀的SQL 引擎非常强调优化器的作用，以确保性能优化方面的出色表现。然而，应牢记优化
器在工作方式方面的一些特点。
优化器需借助在数据库中找到的信息。
这样的信息有两种类型：普通统计数据（须确保数据合适）、数据定义中重要的声明性信息。如
果错误地将反映数据关系的重要语义信息写在触发器程序中，甚至写在应用代码中，会导致优
化器无法利用这些重要信息，势必影响到优化器的优化效果。
能够进行数学意义上的等价变换，优化效果才能最佳。
对于查询中的非关系部分，优化器可借助的理论基础不多，优化结果和原始语句有意无意指定
的方式相差无几。
优化器考虑整体响应时间。
比较大量执行方式的备选方案要花时间。最终用户只看到总共花费的时间，并不知道优化处理
和查询执行各花了多少时间。优化器很聪明，对于预期耗时很长的查询执行，优化器会多花一
些时间（当然有个上限）来改善性能。如果是个 20 路关联（20…way join）——这在一些应用
中并不稀奇——就比较麻烦，优化器必须让步，因为要考虑的组合情况太多了，何况还要同时
考虑合成视图和子查询。所以，一个独立执行的查询，优化效果可能非常好；但若把它嵌入到
一个更复杂的查询内部时，其优化效果可能不佳。
优化器改善的是独立的查询。
然而，优化器无法使独立的查询联系起来。所以，通过过程性编程提取数据，而后将数据传递
给后续查询，优化器就无法进行优化了。
总结：如果是若干个小查询，优化器将个个优化；如果是一个大的查询，优化器会将它作为一
个整体优化。
…………………………………………………………Page 35……………………………………………………………
SQL
掌握SSQQLL艺术的五大要素
Five Factors Governing theArtof SQL
本章的第一节已详细讨论了SQL包含的关系和非关系特性，及其对优化器有效工作的影响。带
着来自第一节的经验教训，接下来我们将集中讨论使用SQL时必须考虑的关键因素。依我看来，
有五大要素：
获得结果集所需访问的数据量
定义结果集所需的查询条件
结果集的大小
获得结果集所涉及的表的数量
多少用户会同时修改这些数据
数据总量
Total Quantity of Data
必须访问的数据总量，是要考虑的最重要因素。一个查询方案，用于只有14 行数据的 emp表
和4行数据的dept表时表现非常出色，但它可能完全不适用于有1 500万行数据的
financial_flows 表与有 500 万行数据的 products 表的join操作。注意，以许多公司的标准来
看，1 500 万行的表并不算特别大。所以结论是，没有确定目标容量之前，很难断定查询执行
的效率。
定义结果集的查询条件
CriteriaDefining the Result Set
在编写 SQL 语句时，多数情况下会涉及 where 子句的条件，而在子查询或视图（普通视图
或内嵌视图）中可能有多个 where 子句。然而，过滤条件的效率有高有低，这会受到其他因
素的极大影响，例如物理实现（将在第5章中讨论）及要访问的数据量等因素。
为了定义结果集，必须从几个方面来考虑，包括过滤、主要SQL语句，以及庞大的数据量对查
询的影响等。这是个复杂的问题，须做深度探讨，详见本章“过滤”一节。
结果集的大小
Size of the Result Set
查询所返回的数据量（或是SQL语句改动的数据量），是个重要且常被忽略的因素。一般而言，
这取决于表的大小和过滤条件的细节，但不都是这样。典型的情况是，若干个独立使用时效率
不高的条件，结合起来使用时会产生极高的效率；例如，以“是否获得理工科或文科学位”作为
查询学生姓名的条件，结果集会非常大，但如果同时使用这两个条件（获得这两个学位），则产
生的结果集就会大幅缩小。
从技术的角度来看，查询结果集的大小并不重要，重要的是最终用户的感觉。用户的耐心，在
很大的程度上和预期返回的记录条数有关：用户只检索一条记录，则他期望非常快，他不会关
心整个数据库有多大。更极端的例子是，查询之后并未返回任何结果：好的开发者都会努力使
…………………………………………………………Page 36……………………………………………………………
返回少量记录或不返回记录的查询尽量快，因为对用户而言，最令人沮丧的事莫过于等待了数
分钟后，看到“无相符数据”的结果；若是按下回车键后马上察觉查询语句有误，而又无法终止
查询，等待就更为恼人。最终用户情愿等待的，是预期返回大量数据时。如果把每个过滤条件
定义的特定结果集看作中间结果，而最终结果是它们的交集（在条件中用and相连）或并集（在
条件中用or相连），那么小型中间结果集的交集很可能为空。换言之，更精确的条件经常是零结
果集产生的主要原因。无论何时，只要查询有可能返回零结果集时，都应该先检查那个最大可
能导致空结果集的条件——尤其是在该检查执行非常快捷时。不用说，条件的顺序与条件所在
上下文的关系十分密切，这在稍后“过滤”一节中讲述。
总结：熟练的开发者应该努力使响应时间与返回的记录数成比例。
表的数量
Number of Tables
查询中涉及的表的数量，自然会对性能有所影响。这不是因为 DBMS 引擎不能很好地执行连
接操作——恰恰相反，现代的DBMS都能非常高效地连接很多表。
Join
连接（JJooiinn）
认为连接效率不高的想法，来自另一个对关系数据库的成见。通常的说法是不该连接太多表，
建议的上限是 5 个。事实上，连接 15 个表也一样可以极高效地执行。但在连接大量表时，
会产生一些额外的问题。
当需要连接多个表时（例如 15 个），按常理你就应该质疑设计的正确性。回忆一下第1章的
内容—— 表的一条记录陈述了某个事实，而且可以将它比作数学的公理，通过连接表的操作，
可衍生出其他事实。但要清楚一点，即哪些是显而易见的事实，可以称为公理；哪些是较不明
显的事实，必须推衍得到。如果我们需要花大量时间来推衍事实，或许最初选择的公理就不合
适。
对于优化器来说，随着表数量的增加，复杂度将呈指数增长。再次提醒，统计优化器通常有
出色的表现，但同时其耗时在查询总响应时间中的比例也很高，尤其是在查询第一次执行时。
如果表比较多，让优化器分析所有可能的查询路径，是非常不切实际的。除非查询语句是为方
便优化器刻意编写的，否则，查询越复杂，优化器越容易“押错宝（bet on the wrong horse）”。
编写涉及许多表的复杂查询时，若可以用好几种截然不同的方式进行连接，最终选择失误的
几率很高。如果我们连接表 A、B、C 和 D，优化器可能没有足够的信息判断出A 直接与 D 连
接的效率会很高。想以 distinct 解决记录重复问题的开发者，也常会遗漏连接条件。
复杂查询与复杂视图
我们必须明白，表面上看到的参与查询的表的数量可能不真实，有些表实际上是视图，它们有
时很复杂。和查询一样，视图的复杂程度也差异极大。视图可以屏蔽字段、记录、甚至是字段
和记录的组合，只让少数有权限的用户可以访问。视图从特定视角反映数据，从表的现存关系
中推衍出新的关系。此时，视图可以看作查询的简略表达方式，这是视图最常见的用途之一。
随着查询复杂度的增加，似乎应该把查询拆成一系列独立视图，每个视图代表复杂查询的一部
分。
总结：表明简单的查询背后，可能隐藏着复杂的视图。
…………………………………………………………Page 37……………………………………………………………
不要走极端，完全不使用视图也不合理，一般它们并无坏处。然而，将视图用在复杂查询中时，
我们多半只对视图返回数据中的一小部分感兴趣——可能是几十个字段中的几个字段——这
时，优化器会试图将简单视图重新并入一段更大的查询语句中。但是，一旦查询复杂到一定程
度，此方法就太复杂了，以至于难以保证效率。
在某些情况下，视图的编写方式，能有效地预防优化器把它并入上级语句中。我已提过 rownum，
那是 Oracle 使用的虚拟字段，用来显示记录最初被查到时的顺序。如果在视图中使用rownum，
复杂性会进一步增加。任何想把参照了 rownum 的视图并入上级查询中的尝试，都会改变后续
rownum 的顺序，所以此时不允许优化器改写查询。于是，复杂查询中这种视图将独立执行。
DBMS 优化器常把视图原样并入语句中，把它当成语句执行的一步来运行（注2），而且只使用
视图执行结果中所需要的部分。
视图中执行的操作（典型的例子是通过join获取ID号对应的描述信息），往往与其所属查询的上
下文无关；或者，查询条件很特殊，会淘汰组成视图的一些表。例如，对若干个表进行union
得到的视图，代表了多个子类型，而上级查询的过滤器只针对其中一个子类型，所以unio其实
是不必要的。将“视图”与“视图中出现的表”进行join也有危险，这会强制多次扫描该表并多次访
问相同记录，但其实只扫描一次就足够了。
当视图返回的数据远多于上级查询所需时，放弃使用该视图（或改用一个较简单的视图），通常
可使效率大为改善。首先，用SQL 查询取代主查询中用到的视图。对视图的组成部分有了整体
的了解之后，要去除严格意义上不必要的部分就容易多了。改用较简单视图的效果也不错，从
查询中去除了不必要部分，执行速度快多了。
许多开发者不愿在复杂查询中，再引入复杂的视图，他们认为这会使情况更为复杂。推导与分
解复杂的SQL表达式的确有点令人生畏，不过，和高中时常做的数学表达式推导也差不多。在
我看来，这有助于形成良好的编程风格，值得花些时间去掌握。对于渴望提高编程技巧的开发
者来说，研究上述技巧有利于对查询内部工作原理�