就算不考虑“10%的记录”这条“经验法则（rule of thumb）”产生的年代（现在的表大小早已今非

昔比了），要知道，返回的记录数除了与期望响应时间有关之外，它本身并无意义。例如，计算

十亿行数据的某字段的平均值，虽然返回结果只有一行，但DBMS 要做大量工作。甚至没有任

何聚合处理，DBMS要访问的数据页的数量也会造成影响。因为要访问的数据页并非只依赖索

引：第3章曾指出，表中记录的物理顺序与索引顺序是否一致，对要访问的页数有极大影响；第

5章将讨论的一些物理实现也会造成影响，由于数据的物理存储方式不同，检索出相同数量的记

and o.custid = c.custid

录所要访问的数据页数量可能差异很大；此外，有的访问路径将以串行方式执行，有的则以大

规模并行（parallelized）方式执行……。因此，再别拿“10%的记录”这根鸡毛当令箭了。

总结：当查询的结果集很大时，索引未必必要。

SQL

语句为了返回结果集或更改数据，必须访问一定数量的数据。“

战斗”

的环境和条件，决定

了我们“

进攻”

那些数据的方法。就如第4

章所讨论的，“

进攻”

取决于：结果集的数据量、必须

访问的数据量、可动用的“

部队”

（过滤条件）。

任何大型的、复杂的查询，都可以被分成一连串较简单的步骤，其中一些步骤可以并行执行，

就像综合战役通常要面对敌军的不同部队。每次战斗的结果差异可能很大，但关键是最后的综

合结果。

当我们分析查询的每个步骤时可能不会深入执行细节，但这些步骤可能的组合数量跟国际象棋

不相上下，可以非常复杂。

本章讨论存取经过适当规范化的数据时，经常遇到的情况。虽然本章主要讨论查询，但也适用

于更新和删除cāo作，只要它们也有where

子句，毕竟要先读取数据才能修改数据。无论是单纯

为了查询、还是更新或删除记录，过滤数据会遇到的最典型情况有九种：

小结果集，源表较少，查询条件直接针对源表

小结果集，查询条件涉及源表之外的表

小结果集，多个宽泛条件，结果取jiāo集

小结果集，一个源表，查询条件宽泛且涉及多个源表之外的表

大结果集

结果集来自基于一个表的自连接

结果集以聚合函数为基础获得

结果集通过简单搜索或基于日期的范围搜索获得

结果集和别的数据存在与否有关

本章将依次讨论上述各种情况。至于例子，有的简单明了，有的较为复杂（来自实际案例）。

虽然案例大小存在差异，但解决问题的模式是相通的。

通常，在执行查询时，应过滤掉所有不属于结果集的数据，这意味着应尽量采用最高效的搜索

条件。决定先执行哪个条件，通常是优化器的工作。但是，正如第4

章所述，优化器必须考虑

大量不同情况——

例如表的物理结构、查询编写方式等，所以优化器未必总能“

理解正确”

。因

此，提高xìng能还有很多事情可做，下面对九种模式的讨论中，每种模式均是如此。

小结果集，直接条件

Small Result Set, Direct Specific Criteria

对于典型的在线jiāo易处理，多为返回小结果集的查询，源表数量较少，查询条件也是“直接”针

对源表的。当我们要通过一组条件查询出少许记录时，首先要注意的就是索引。

一般而言，通过一个表或通过两个表的连接查询较少记录，只要确保查询有适当的索引支持即

可。然而，当很多表连接在一起，并且查询条件要参照不同的表时（例如TA 和TB），会面临

连接顺序的问题。连接顺序的选择，取决于如何更快地过滤不想要的记录。如果统计数据足够

精确地反映了表的内容，优化器有可能对连接顺序做出适当选择。

当查询仅返回少量记录，且过滤条件直接针对源表时，我们必须保证这些过滤条件高效；对于

非常重要的条件，必须事先为相应字段加上索引，以便查询时使用。

索引可用xìng

Index Usability

如第3章所述，对某字段使用函数时，则该字段上的索引并不能起作用。当然，你可以建立函数

索引（functional index），这意味着要对函数的结果加索引，而不是为字段加索引。

注意，“函数调用”不光是指“显式函数调用”。如果你将某类型的字段与一个不同类型的字段或

常量进行比较，则DBMS会执行“隐式类型转换”（隐式调用一个转换函数），如你所料，这会对

xìng能造成影响。

一旦确定重要的搜索条件上有索引，而查询编写方式也的确能因索引而提高xìng能，我们还须进

一步区别如下两种情况：

使用唯一xìng索引（unique index）检索单条记录

非唯一xìng索引（non-unique index）或基于唯一xìng索引的范围扫描（range scan）

查询的效率与索引的使用

Query Efficiency and Index Usage

需要连接（join）表时，唯一xìng索引非常有用。然而，当程序获得的原始输入（primitive input）

不是查询语句需要的主键值时，必须通过编程来解决转换问题。

这里的“原始输入”指程序接受的数据，可能由使用者输入，也可能从文件中读入。如果查询语

句需要的主键值本身，就是根据原始输入利用另一个查询所获得的结果，则说明设计不合理。

因为这意味着一个查询的输出被用作另一个查询的输入，应该考虑合并这两个查询。

总结：优秀的查询未必来自优秀的程序。

数据散布

Data Dispersion

当条件是“非唯一xìng”的，或者条件以唯一xìng索引上的范围来表达时，DBMS 就必须执行范围扫

描。例如：

where custcomr_id between . .. and ...

或：

where supplier_ncom like 'SOMENAME%'

键对应的记录很可能散布在整个表中，而基于成本的优化器知道这一点。所以，索引范围扫描

会使DBMS 核心逐一读取表的存储页，此时，优化器会决定DBMS 核心忽略索引对表进行

扫描。

如第5章所述，许多数据库系统提供了诸如分区（partition）和聚集索引（clustered index）等功

能，直接将可能一并读取的数据存储在一起。其实，数据chā入处理也常造成数据丛聚（clumping）

保存的现象：如果每条记录chā入表时都要加时间戳（tcomstamp），则相继chā入的记录会彼此紧

邻（除非我们采取特殊手段避免资源竞争，见第9章的讨论）。这其实没有必要，而且关系理论

中也没有“顺序”的概念，但在实际中却很可能发生。

因此，当我们在时间戳字段的索引上执行范围扫描、查询时间上接近的索引项时，这些记录可

能彼此紧邻——如果特

松语文学免费小说阅读_www.16sy.com