SQL语言艺术(PDF格式)-第7部分

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



上等价的不同优化方案做出权衡，产生有可能是最优的查询执行方案。　



然而，要记住的关键一点是，尽管优化器在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