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

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

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




采用嵌套查询,在数值表达式中建议连接关系,这样不必大幅修改SQL子句: 



select (select list) 

from (select ttraoma。txnum; 

ttraoma。bkcod; 

ttraoma。trscod; 

ttraoma。pdtcod; 

ttraoma。objtyp; 

。。。 

from ttraoma; 

tstgtstg_a; 

ttrcapp ttrcap_a 

where tstg_a。chncod =:7 


…………………………………………………………Page 66……………………………………………………………

andtstg_a。stgnum =:8 

andtstg_a。risktyp =:4 

andttraoma。txnum =tstg_a。txnum 

andttrcap_a。colcod =:0 

andttrcap_a。refcod =:5 

andttraoma。trscod =ttrcap_a。valnumcod) a; 

ttexttex_a; 

ttrcapp ttrcap_b; 

tbooks; 

topeoma; 

ttexttex_b; 

ttypobj; 

tpdt; 

trgppdt 

where (a。txnum=topeoma。txnum ) 

and(a。bkcod =tbooks。trscod ) 

and(ttex_b。trscod =tbooks。permor ) 

and(ttex_a。nttcod =ttrcap_b。valnumcod ) 

and(ttypobj。objtyp =a。objtyp) 

and(a。trscod=ttex_a。trscod ) 

and(ttrcap_b。colcod =:1) 

and(a。pdtcod =tpdt。pdtcod ) 

and(tpdt。risktyp=trgppdt。risktyp ) 

and(tpdt。riskflg=trgppdt。riskflg) 

and(tpdt。pdtcod =trgppdt。pdtcod ) 

and(tpdt。risktyp=:2) 

and(tpdt。riskflg=:3) 

and(ttrcap_b。refcod =:6) 

通常,没有必要采用非常具体的方式和难以理解的提示,其实,提供正确的最初指导就可使优 

化器找到正确的执行路径。嵌套查询是个不错的选择,它使表的关联变得明确,而SQL语句的 

阅读也相当容易。 



总结:混乱的查询会让优化器困惑。结构清晰的查询及合理的连接建议,通常足以帮助优化器 

提升性能。 



大结果集 



LargeResult Set 



无论结果集是如何获得的,只要结果集“很大”,就符合我们下面要讨论的“大结果集”的情况。 


…………………………………………………………Page 67……………………………………………………………

批处理环境下,产生大结果集是明智的。当需要返回大量记录时,只要查询条件的可选择性不 

高,那么即使结果集只占表中数据量的一小部分,也会引起DBMS引擎执行全表扫描;只有某 

些数据仓库例外,我们将在第10章中讨论之。 



如果查询返回几万条记录,那么使用索引是没有意义的,无论索引用于产生最终结果,还是用 

于复杂查询的中间步骤。相比而言,借助哈希或合并连接进行全表扫描是合适的。当然,强力 

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

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

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

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

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

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

引等避免访问表的技术。 

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

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

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

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



还要重点关注子查询的使用。处理大量记录时,关联子查询(Correlatedsubquery)是性能杀手。 

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

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

操作得到结果集。 

查询执行的并行化(parallelism)也是个好主意,不过只应在“并发活动会话数(concurrentlyactive 

sessions)”很少(典型情况为批处理操作)时才这么做。并行化是由 DBMS 实现的,如果有可 

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

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

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

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

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

基于一个表的自连接 

Self…Joins on OneTable 

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

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

致性,同一个表中没有重复记录。于是,才能够建立同一个表之间的连接关系:使用同一查询 

从同一表中选择不同记录的集合(可以相交),然后连接它们,就好像它们来自不同表一样。本 

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

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



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

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

select f。flight_number; 

a。airport_name departure_airport; 


…………………………………………………………Page 68……………………………………………………………

b。airport_name arrival_airport 

from flights f; 

airports a; 

airports b 

where f。dep_iata_code =a。iata_code 

andf。arr_iata_code =b。iata_code 

此时,一般规则仍然适用:重点保证索引访问的高效。但是,如果此时索引访问不太高效怎么 

办呢?首当其冲地,应避免“第一轮处理丢弃了第二轮处理所需的记录”。应该通过一次处理收 

集所有感兴趣的记录,再使用诸如case 语句等结构分别显示记录,第11章将详细说明这种方法。 

非常微妙的是,有些情况看似与“机场的例子”很像,但其实不然。例如,如何利用一个保存“定 

期累计值”(注3)的表,显示每个时间段内累计值的增量?此时,该表内的两个不同记录间虽 

然有关联,但这种关联很弱:两个记录之所以相关,是因为它们的时间戳之间有前后关系。而 

连接两个flights表是通过airports表进行的,这种关联很强。 

例如,时间段为5分钟,时间戳以“距参照日期多少秒(seconds elapsed since a reference date)” 

表示,则查询如下: 

select a。timestamp; 

a。statistic_id; 

(b。counter …a。counter)/5hits_per_minute 

from hit_counter a; 

hit_counter b 

where b。timestamp =a。timestamp+300 

andb。statistic_id =a。statistic_id 

order bya。timestamp; a。statistic_id 



上述脚本有重大缺陷:如果第二个累计值不是正好在第一个累计值之后5分钟取得的,那么就无 

法连接这两条记录。于是,我们改以“范围条件”定义连接。查询如下: 

select a。timestamp; 

a。statistic_id; 

(b。counter …a。counter)*60/ 

(b。timestamp …a。timestamp) hits_per_minute 

from hit_counter a; 

hit_counter b 

where b。timestamp between a。timestamp+200 

anda。timestamp +400 

andb。statistic_id =a。statistic_id 

order bya。timestamp; a。statistic_id 

这个方法还是有缺陷:前后两次计算累计值的时间间隔,如果不介于 200 到 400 秒之间(例 

如取样频率改变了),如此之大的时间跨度就会引起风险。 

我们还有更安全的方法,就是使用基于“记录窗口(windows of rows)”的OLAP函数(OLAP 

function)。难以想象,这种本质上不太符合关系理论的技术可以显著提升性能,但应作为查询 

优化的最后手段使用。借助partition 子句,OLAP函数支持“分别处理结果集的不同子集”,比如 


…………………………………………………………Page 69……………………………………………………………

分别对它们进行排序、总计等处理。借助OLAP 函数row_number(),可以根据 statistic_id 建立 

子集,然后按时间戳增大的顺序为不同统计赋予连续整数编号,接下来,就可以连接statistic_id 

和两个序号了,如下例子所示: 

select a。timestamp; 

a。statistic_id; 

(b。counter …a。counter)*60/ 

(b。timestamp …a。timestamp) 

from (select timestamp; 

statistic_id; 

counter; 

row_number( )over(partition bystatistic_id 

order bytimestamp) rn 

from hit_counter) a; 

(select timestamp; 

statistic_id; 

counter; 

row_number( )over(partition bystatistic_id 

order bytimestamp) rn 

from hit_counter) b 

where b。rn=a。rn+1 

anda。statistic_id =b。statistic_id 

order bya。timestamp; a。statistic_id 



Oracle等DBMS支持OLAP 函数 lag(column_name; n)。该函数借助分区()和排序(),返回 

column_name之前的第n个值。如果使用lag()函数,我们的查询甚至执行得更快——比先前的查 

询大约快25%。 

select timestamp; 

statistic_id; 

(counter …prev_counter) *60/ 

(timestamp …prev_timestamp) 

from (select timestamp; 

statistic_id; 

counter; 

lag(counter;1)over(partition bystatistic_id 

order bytimestamp) prev_counter; 

lag(timestamp; 1)over(partition bystatistic_id 

order bytimestamp) prev_timestamp 

from hit_counter) a 

order bya。timestamp; a。statistic_id 

很多时候,我们的数据并不像航班案例中那样具有对称性。通常,当需要查找和最小、最大、 

最早、或最近的值相关联的数据时,首先必须找到这些值本身(此为第一遍扫描,需比较记录), 


…………………………………………………………Page 70……………………………………………………………

接下来的用这些值作为第二遍扫描的搜索条件。而以滑动窗口(sliding window)为基础的OL
返回目录 上一页 下一页 回到顶部 0 0
未阅读完?加入书签已便下次继续阅读!
温馨提示: 温看小说的同时发表评论,说出自己的看法和其它小伙伴们分享也不错哦!发表书评还可以获得积分和经验奖励,认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦!