友情提示:如果本网页打开太慢或显示不完整,请尝试鼠标右键“刷新”本网页!阅读过程发现任何错误请告诉我们,谢谢!! 报告错误
一世书城 返回本书目录 我的书架 我的书签 TXT全本下载 进入书吧 加入书签

SQL语言艺术(PDF格式)-第10章

按键盘上方向键 ← 或 → 可快速上下翻页,按键盘上的 Enter 键可回到本书目录页,按键盘上方向键 ↑ 可回到本页顶部!
————未阅读完?加入书签已便下次继续阅读!




者来说,研究上述技巧有利于对查询内部工作原理的深入了解,常常使你受益匪浅。 



总结:当视图返回不必要的元素时,别把视图内嵌在查询中,而是应将视图分解,将其组成部 

分加到查询主体中。 



并发用户数 



Number of other Users 



最后,在设计 SQL 程序时,并发性(concurrency)是个必须认真对待的因素。写数据库时需 

要关注并发性:是否存在数据块访问争用(block…access contention)、阻塞(locking)、或闩 

定(latching)(DBMS内部资源阻塞)等重要问题;甚至有时,为保证读取一致性(read 

consistency)也会导致某种程度的资源争用。任何服务器的处理能力都是有限的,不管其说明 

书有多令人震撼。在机器相同的情况下,很少并发或没有并发操作时设计可能是完美的,但对 

有大量并发操作的情况未必完美。排序操作可能没有足够内存可用,于是转而求助于磁盘,引 

发了新的资源争用……一些计算密集型(CPUintensive)操作——例如负责复杂计算的函数、 

索引区块的重复扫描,均可引起计算机负荷过多。我遇到过一些案例,增加物理 I/O 会使任务 

执行效率更高,因为其中计算密集操作的并发执行程度很高,一个进程刚因等待 I/O 而阻塞, 

被释放的CPU就被另一个进程占用了,这样一来CPU资源就被充分利用了。一般而言,我们必 

须考虑特定商业任务的整体吞吐量(throughput),而不是个别用户的响应时间(response…time)。 


…………………………………………………………Page 38……………………………………………………………

注意 



第9章将更详细地探讨并发性。 



过滤 



Filtering 



如何限定结果集是最关键的因素之一,有助于你在编写 SQL 语句时判断该用哪些技巧。用来 

过滤数据的所有准则,通常被视为是 where 子句中各种各样的条件,我们必须认真研究各种 

where 子句(及 having 子句)。 



过滤条件的含义 



Meaning of Filtering Conditions 

若从SQL语法来看,where子句中表达的所有过滤条件当然大同小异。但事实并非如此。有些 

过滤条件通过关系理论直接作用于select 运算符:where子句检查记录中的字段是否与指定条 

件相符。但其实,where 子句中的条件还可以使用另一个关系运算符 join。自从 SQL92 出现 

join 语法后,人们就试图将“join过滤条件”(位在主 from 子句和 where 子句之间)和“select 

过滤条件”(位于where子句内)区分开来。从逻辑上讲,连接两个(或多个)表建立了新的关 

系。 

下面是个常见的连接(join)的例子: 

select 。。。。。 

from t1 

inner join t2 

on t1。join1 = t2。joind2 

where 。。。 



假设表t2中有一字段c2,该不该把 c2上的条件当作 inner join 的额外条件呢?即是否应认为参 

与连接的不是“t2表”而是“t2表的子集”呢?或者,假设where 子句中有一些关于t1 字段的条件, 

那么这些条件是否会应用到 t1 连接 t2 的结果呢?连接条件放在何处应该都一样,然而其运 

行效率却会因优化器不同而异。 



除了连接条件和简单的过滤条件之外,还有其他种类的条件。例如,规定返回的记录集为某种 

子类型的条件,以及检查另一个表内是否存在特定数据的条件。虽然从 SQL 语法上看它们相 

似,但在语义上却未必完全相同。有时条件的计算顺序无足轻重,但有时却影响重大。 



下面的例子说明了条件计算顺序的重要性,实际上,在许多商用软件包中都能找到这样的例子。 

假设有个 parameters 表,它包含字段:parameter_name、parameter_type、 



parameter_value,无论由parameter_type定义了什么参数属性,其中 parameter_ value 均以 

字符串表示。(从逻辑上来说,上述情况堪比罗密欧与茱莉叶的悲剧,因为属性parameter_value 

所表示的领域类型非常多,所以违反了关系理论的主要规则。)假设进行如下查询: 

  select * from parameters 


…………………………………………………………Page 39……………………………………………………………

  where parameter_name like'%size' 

  and parameter_type = 'NUMBER' 



在这个查询中,无论先计算两个条件中的哪一个,都无关紧要。然而,如果增加了以下条件, 

计算的顺序就变得非常重要了,其中int()是将字符转换为整数值的函数: 

   and int(parameter_value) 》 1000 



这时,parameter_type上的条件必须先计算,而parameter_value上的条件后计算,否则会因为 

试图把非数字字符串转换为整数,而造成运行时错误(假设 parameter_ type字段的类型定义 

为char)。如果你无法向数据库说明这一点,那么优化器也无从知道哪个条件应该有较高的优先 

权。 



总结:查询条件是有差异的,有的好,有的差。 



过滤条件的好坏 



Evaluation of Filtering Conditions 

编写 SQL 语句时,应首先考虑的问题是: 



  哪些数据是最终需要的,这些数据来自哪些表? 



  哪些输入值会传递到 DBMS 引擎? 

  哪些过滤条件能滤掉不想要的记录? 



然而要清楚的是,有些数据(主要是用来连接表的数据)可能冗余地存储在几个表中。所以, 

即使所需的返回值是某表的主键,也不代表这个表必须出现在from子句中,这个主键可能会以 

外键的形式出现在另一个表中。 



在编写查询之前,我们甚至应该对过滤条件进行排序,真正高效的条件(可能有多个,涉到不 

同的表)是查询的主要驱动力,低效条件只起辅助作用。那么定义高效过滤条件的准则是什么 

呢?首先,要看过滤条件能否尽快减少必须处理的数据量。所以,我们必须倍加关注条件的编 

写方式,下面通过例子说明这一点。 



蝙蝠车买主 



假设有四个表: customers、orders、orderdetail、articles,如图4…5所示。注意,图中各表的 

方框大小不同,这代表各表的数据量大小,而不代表字段数量;加下划线的字段为主键。 

现在假设 SQL 要处理的问题是:找出最近六个月内居住在Gotham市、订购了蝙蝠车的所有客 

户。当然,编写这个查询有多种方法,ANSISQL的推崇者可能写出下列语句: 

  select distinct c。custname 

  from customersc 

  join orders o 

  on o。custid = c。custid 

  join orderdetail od 

  on od。ordid = o。ordid 


…………………………………………………………Page 40……………………………………………………………

  join articles a 

  on a。artid = od。artid 

  where c。city= 'GOTHAM' 

  and a。artname = 'BATMOBILE' 

  and o。ordered 》= somefunc 

其中,somefunc是个函数,返回距今六个月前的具体日期。注意上面用了distinct,因为考虑到 

某个客户可以是大买家,最近订购了好几台蝙蝠车。 

暂不考虑优化器将如何改写此查询,我们先看一下这段代码的含义。首先,来自customers表的 

数据应只保留城市名为 Gotham 的记录。接着,搜索orders表,这意味着custid字段最好有索 

引,否则只有通过排序、合并或扫描orders表建立一个哈希表才能保证查询速度。对orders表, 

还要针对订单日期进行过滤:如果优化器比较聪明,它会在连接(join)前先过滤掉一些数据, 

从而减少后面要处理的数据量;不太聪明的优化器则可能会先做连接,再作过滤,这时在连接 

中指定过滤条件利于提高性能,例如: 

  join orders o 

  on o。custid = c。custid 

  and a。ordered 》= somefunc 



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

键为(ordid; artid),即ordid为索引的第一个属性,那么我们可以利用索引找到与订单相关的记 

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

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

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

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

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

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

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

   select distinct c。custname 

   from customersc; 

   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。artname = 'BATMOBILE' 

   and o。ordered 》= somefunc 



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

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

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


…………………………………………………………Page 41……………………………………………………………

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

特点。 



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

却能将另一个病人医死。 



蝙蝠车买主的进一步讨论 



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

原因在于,即使我们遗漏了连接的某个条件,distinct也会使查询“看似正确”地执行——无可否 

认,较旧的SQL语法在此方面问题较大,但ANSI/SQL92 在通过多个字段进行表的连接时也可 

能出现问题。发现重复数据容易,但发现数据不准确很难,所以避免在最高层使用distinct应该 

是一条基本规则。 



发现结果不正确更难,这很容易证明。前面使用 distinct 返回客户名的两个查询,都可能返回 

不正确结果。例如,如果恰巧有多位客户都叫“Wayne”,distinct不但会剔除由同个客户的多张 

订单产生的重复项目
返回目录 上一页 下一页 回到顶部 0 0
未阅读完?加入书签已便下次继续阅读!
温馨提示: 温看小说的同时发表评论,说出自己的看法和其它小伙伴们分享也不错哦!发表书评还可以获得积分和经验奖励,认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦!