《SQL语言艺术(PDF格式)》第11章

上等价的不同优化方案做出权衡，产生有可能是最优的查询执行方案。　
然而，要记住的关键一点是，尽管优化器在SQL查询的“非关系操作层”也偶有用途，但以关系　
理论为支柱的优化器主要用于关系操作层。SQL查询的等价变换还提醒我们：SQL原本就是一　
种声明性语言（declarativelanguage）。换言之，SQL应该是用来表达“要做什么”、而非“如何来　
做”的。理论上讲，从“要做什么”到“如何来做”的任务就是由优化器来完成的。　
在第1章、第2章中讨论的SQL查询比较简单，但即使从编写技巧层面来说，拙劣的查询语句也　
会影响优化器的效率。切记，关系理论的数学基础为数据处理提供了非常严谨的逻辑支持，因　
此SQL艺术本应注重减小“非关系操作层”的厚度，即尽量在关系操作层完成大部分处理，否则　
优化器在“非关系操作层”难以保证返回的结果数据和原始查询执行的结果一样。　
另外，在执行非关系操作时（这里非关系操作不严格地定义为针对已知结果集的操作），应专注　
于操作那些解决问题所必需的数据，不要画蛇添足。和当前记录不同，有限数据集必须以某种　
方式进行临时存储（内存或硬盘），这会带来惊人的开销。随着结果集数据量的增大，这种开销　
会急剧加大，尤其是在主存所剩无几的时候。主存不足会引发硬盘数据交换等开销很高的活动。　
而且，别忘了“索引所指的是硬盘地址，并非临时存储地址”，所以数据一旦进行临时存储，就意　
味着我们向最快的数据访问方式说再见了（哈希方式可能例外）。　
一些SQL方言会误导用户，使他们认为自己仍在关系世界中——但其实早就不是关系操作了。　
举个简单的例子：不是经理的员工当中，哪五个人收入最高？这是个现实生活中很合理的问题，　
…………………………………………………………Page　33……………………………………………………………
但它包含了明显的非关系描述。“找出不是经理的员工”是其中的关系操作部分，由此获得一个有　
限的员工集合，然后排序。有些SQL方言通过在select语句中增加特殊子句来限制返回的记录数，　
很显然，排序和限制记录数都是非关系操作。其他SQL方言（这里主要是指　Oracle）则采用另　
外的机制，即用一个名为rownum的虚拟字段（dummycolumn）为查询结果编号——这意味着　
编号工作发生在关系操作阶段。如果查询语句如下：　
select　empname；　salary　
from　employees　
where　status　！=　"EXECUTIVE"　
and　rownum