sql语言艺术

查询的识别

 

查询的识别

总结：易识别的语句有助于定位性能问题。

尽量给语句添加注释或使用oracle自带的函数来标明应用的信息。

 

保持数据库连接稳定

总结：数据库连接和交互好似万里长城——长度越长，传递消息越耗时。

减少数据库的连接次数，使用数据库连接池。

 

战略优先于战术

总结：考虑解决方案的细节之前，先站得远一些，把握大局。

可以从业务的角度思考，想想数据的来源与去处是不是有其他路径可寻。

 

先定义问题，再解决问题

总结：先打基础，再赶时髦：摆弄新工具之前，先把手艺学好。

尽量减少使用新技术，这些往往没有经过时间的检验，虽然有可能解决当前的问题，但是在未来可能存在隐患。

 

直接操作实际数据

总结：暂时工作表意味着以不太合理的方式存储更多信息。

减少使用临时表，尽量直接操作实际表。

 

用SQL处理集合

总结：几千个语句，借助游标（cursor）不断循环，很慢。换成几个语句，处理同样的数据，

还是较慢。换成一个语句，解决上述问题，最好。

 

动作丰富的SQL语句

总结：尽可能多地把事情交给数据库优化器来处理。

避免使用过程逻辑，写多个sql，业务需求尽量写成一个sql，这样数据库优化器可以进行优化。

 

充分利用每次数据库访问

总结：在合理范围内，利用每次数据库访问完成尽量多的工作。

尽量一次查询所有的字段。

 

接近DBMS核心

总结：代码喜欢SQL内核——离核心越近，它就运行得越快。

尽量使用数据库自带函数实现业务逻辑，而不要使用过程块语句去封装实现相应逻辑。

 

只做必须做的

总结：没必要编程实现那些数据库隐含实现的功能。

 

SQL语句反映业务逻辑

总结：检查数据库活动，看它是否与当时正进行的业务活动保持合理的一致性。

 

把逻辑放到查询中

总结：只要有可能，应尽量把条件逻辑放到SQL语句中，而不是SQL的宿主语言中。

 

一次完成多个更新

总结：有可能的话，用一个语句处理多个更新；尽量减少对同一个表的重复访问。

 

慎用自定义函数

自定义函数的方式阻碍了基于开销的优化器（cost-based optimizer，CBO）对整个查询的优化效果。

总结：优化器对自定义函数的代码无能为力。

 

简洁的SQL

总结：SQL是声明性语言（declarative language），所以设法使你的代码超越业务过程的规格说明。

 

SQL的进攻式编程

总结：以概论为基础进行编程。假设最可能的结果；不是的确必要，不要采用异常捕捉的处理方式。

 

精明地使用异常（Exceptions）

总结：异常处理会迫使我们采用过程式逻辑。应始终使用声明式SQL，尽量预测可能的异常情况。

 

SQL的本质

 

SQL与数据库

总结：千万别把SQL查询的执行过程中真正的关系操作和附加的展现层（presentation layer）功能混为一谈。

 

SQL与优化器

总结：为了取得好的优化效果，应将大部分工作安排在关系层。

 

优化器的有效范围

总结：如果是若干个小查询，优化器将个个优化；如果是一个大的查询，优化器会将它作为一个整体优化。

 

掌握SQL艺术的五大要素

 

获得结果集所需访问的数据量

定义结果集所需的查询条件

结果集的大小

获得结果集所涉及的表的数量

多少用户会同时修改这些数据

 

复杂查询与复杂视图

总结：表明简单的查询背后，可能隐藏着复杂的视图。

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

分加到查询主体中。

 

过滤

过滤条件的含义

总结：查询条件是有差异的，有的好，有的差。

 

过滤条件的好坏

总结：保证SQL 语句返回正确结果，只是建立最佳SQL语句的第一步。

 

大数据量查询

总结：尽早过滤掉不需要的数据。

 

取出数据在表中的比例

总结：当查询的结果集很大时，索引未必必要。

 

无论是单纯为了查询、还是更新或删除记录，过滤数据会遇到的最典型情况有九种：

小结果集，源表较少，查询条件直接针对源表

小结果集，查询条件涉及源表之外的表

小结果集，多个宽泛条件，结果取交集

小结果集，一个源表，查询条件宽泛且涉及多个源表之外的表

大结果集

结果集来自基于一个表的自连接

结果集以聚合函数为基础获得

结果集通过简单搜索或基于日期的范围搜索获得

结果集和别的数据存在与否有关

 

小结果集，直接条件

 

查询的效率与索引的使用

总结：优秀的查询未必来自优秀的程序。

 

数据散布

总结：并非所有明确的条件都适合加索引。特别是，频繁更新的字段会增加索引维护的成本。

 

条件的“可索引性”

总结：如果必须进行全表扫描，表上的索引就没用了。

 

总结：内嵌查询可以简化查询，但若使用不慎，可能造成重复处理。

 

小结果集，间接条件

总结：如果要使用子查询，在选择关联子查询、还是非关联子查询的问题上，应仔细考虑。

 

多个宽泛条件的交集

总结：为现存的查询增加搜索条件，可能彻底改变先前的构想：修改过的查询成了新查询。

 

多个间接宽泛条件的交集

总结：记住，你应该详细说明所有强迫DBMS 做的事。

 

总结：混乱的查询会让优化器困惑。结构清晰的查询及合理的连接建议，通常足以帮助优化器提升性能。

 

大结果集

 

基于一个表的自连接

总结：要理解优化器如何看待你的系统，就必须理解你的数据和数据分布方式。

 

通过聚合获得结果集

总结：聚合操作的数据应尽量少。

 

后面主要是提供了一些sql编写技巧。

 

----摘自《SQL语言艺术》