Relation Databases Index Design and the Optimizers翻译

第三章 SQL处理

介绍

我们现在已经对表和索引的结构有一些了解了；我们也理解和缓冲池，磁盘，磁盘服务器相关的一些对象，还有这些东西怎么让数据通过SQL能够读取。我们现在该看一下SQL本身是如何处理的。和以前一样，很多东西取决与单个关系数据库如何处理SQL；有很多相似之处，但是也有很多的不同。我们会先大概描述底层是怎么处理的，这样避免把数据库具体的东西和基本概念搞混了。合适的时候我们会将数据库具体细节。很多处理的细节在整本书里面都会不断的提到，要等到合适的时候。请记住，书末尾的词汇表总结了这章中使用的术语。

PREDICATES

一个WHERE子句包括一个或者多个predicates(搜索参数)，下面展示了三个简单的predicates

SQL 3.1

WHERE SEX = ‘M’

AND

(WEIGHT > 90

OR

HEIGHT > 190)

SEX = ‘M’
WEIGHT > 90
HEIGHT > 190

他们也可以被看成是两个符合predicates
WEIGHT > 90 OR HEIGHT > 190

4000
SEX = ‘M’ AND (WEIGHT > 90 OR HEIGHT > 190)

Predicates是索引设计的主要出发点，如果一个索引支持selec语句中所有的predicates，那么查询优化器很可能构建一条有效的数据获取路径。

注释

在Chris Date的n本书里面，他很不想使用predicates这个术语，我们还是按照传统数据库术语，在这里把conditions称为predicates。严格来讲，这样用是不对的，更准确的术语是条件表达式或者真值表达式。

查询优化器和数据存取路劲

关系数据库的一个长期保持的优点是，数据通常都是按照他应该被存取的方式进行存取的。如何存取的决策是由一个叫做查询优化器的组件进行的。不同的数据库系统，查询优化器各不相同，而且未来还是一样保持不同。但是他们都是通过数据库系统收集的统计信息，尽可能有效的存取数据。当然查询优化器是SQL处理的核心，也是本书的核心。在sql语句被执行之前，查询优化器必须判断应该如何存取数据；如果可能的话，应该使用哪一个索引，是不是应该使用辅助随机读，还有其他一堆事情。所有的这些信息都体现在存取路径上。例如我们在章节2用过的，这里展示在图3.1中的，存取路径定义了一个，如何对一部分索引进行扫描，还有接下来如何从需要的表页中读取。

索引片段和匹配字段

按照图3.1所示，一小片段的索引会被按顺序扫描，然后对于值在100到110之间的索引行，使用同步读，相应的行会被从表里面读出来，除非这些页已经在缓冲池里面。存取路径的成本取决与索引片段的大小。这取决于predicate所描述的范围。 越大的索引片段，需要顺序读取的索引页就越多，就有越多的索引行被处理。但是成本真正增加的地方来自于对表的同步读次数，大概10ms每个表页。类似的，越小的索引片段会减小索引读取成本，但是主要的性能节约来自于对表页更少的同步读次数。 所以索引片段的大小非常重要。不是所有的关系数据库都使用索引片段这个术语，他们都使用自己的术语，但是我们认为索引片段更能描述的清楚这个情况，我们在各种数据库都能这么用。另一种描述索引片段的方式是定义匹配字段的数量，在我们的例子中，我们只有一个匹配的字段
，这个匹配字段定义了我们索引片段的厚度，如果我们有第二个匹配字段，同时在索引和where子句中，两个字段一起可以定义一个更小的索引片段。更少的索引处理往往导致的表页同步读也更少，这个导致的结果更重要。

索引筛选和筛选字段

有时字段同时出现在where子句和索引中，但是因为其他原因，不可能再定义索引片段，这个问题很复杂，整本书都会不断去解决这个问题。现在可以说的是，不是所有索引中的字段都可以用来定义索引片段。但是这些字段仍然可以用来减少对表页的同步读次数。作用很重要。我们把这些字段叫做screening字段，很多数据库系统也这么叫。 因为这就是这些字段做的事情。他们减少了对表行的读，因为可以用索引中的这字段来决定避免某些对表页读写。现阶段先不太深入，我们先提供一个初始的理解，理解是否predicates如何参与匹配和筛选过程。.