sql是的全称是structured query language(结构化查询语言)。sql是一个在80年代中期被使用的工业标准数据库查询语言。不要把sql语
sql是的全称是structured query language(结构化查询语言)。sql是一个在80年代中期被使用的工业标准数据库查询语言。不要把sql语言与商业化产品如microsoft sql server或开源产品mysql相混淆。所有的使用sql缩略词的这些都是sql标准的一部分。
更多oracle相关信息见oracle 专题页面 ?tid=12
一、sql tuning之前的调整
下面这个粗略的方法能够节省数千小时乏味的sql tuning，因为一旦调整它将影响数以百计的sql查询。记住，你必须优先调整它，否则后
续的优化器参数改变或统计信息可能不会有助于你的sql调整。
记住，你应当总是优先考虑系统级别的sql tuning，否则在sql tuning之后再进行调整可能会使得你先前调整的sql功亏一篑。
1、优化系统内核
首先应当考虑调整磁盘和网络i/o子系统(象raid，dasd带宽，网络等)去最小化i/o时间，网络包的大小以及调度频率。
2、调整优化器统计信息
应当定期收集和存储优化器的统计信息以便优化器根据数据的分布生成最佳的执行计划。此外，直方图有助于优化表的连接以及为有倾斜的
where 子句谓词信息做出正确的访问决定。
3、调整优化器参数
下列优化器参数应当被调整
optimizer_mode， optimizer_index_caching， optimizer_index_cost_adj
4、优化实例
下列实例/会话级别参数将影响sql性能
db_block_size，db_cache_size， and os parameters (db_file_multiblock_read_count， cpu_count， &c)，
5、使用索引或物化视图调整sql访问负载
oracle 10g之后可以使用sql access advisor来为sql生成索引或物化视图的建议。应当总是使用索引来优化sql，特别是基于函数的索引。
oracle 11g的改进：
oracle 11g中新增的sql performance analyzer (spa)是一个从整体上加快sql调整的新特性。
通过spa，一旦创建一个负载(称为sql tuning set，或者sts)，oracle将根据不同环境情况，使用复杂的预测模块重复的执行工作负载(使
用回归测试方法)，来得到当前负载的最佳sql执行计划。使用spa，我们可以预测一个sql负载基于系统变化造成的影响，以及预测象参数
调整，系统schema调整，硬件调整，操作调整，oracle升级之后当前sql语句的响应时间。更多详细的细节请参考:oracle 11g new feature
当运行环境，oracle实例以及对象被调整之后，更多地关注则是数据库中的性能影响最大的单个单个的sql语句。下面将针对单个sql调整给
出一些常规建议以提高 oracle 性能。
二、oracle sql tuning的目标
oracle sql tuning是一个复杂的课题。oracle tuning: the definitive reference 这整本书描述了关于sql tuning的细节。尽管如此，
为了提高系统系能，oracle dba应当遵从下面一些总的指导原则。
1、sql tuning 目标
是以最小的数据库访问次数提取更多地数据行来生成最佳的执行计划(尽可能最小化物理读(pio)与逻辑读(lio)。
指导原则
移除不必要的大型全表扫描
大型表的全表扫描将产生庞大的系统i/o且使得整个数据库性能下降。优化专家首先会评估当前sql查询所返回的行数。最常见的办
法是为走全表扫描的大表增加索引。b树索引，位图索引，以及基于函数的索引等能够避免全表扫描。有时候，对一些不必要的全表扫
描通过添加提示的方法来避免全表扫描。
缓存小表全表扫描
有时候全表扫描是最快的访问方式，管理员应当确保专用的数据缓冲区(keep buffer cache，nk buffer cache)对这些表可用。在
oracle 8 以后小表可以被强制缓存到 keep 池。
使用最佳索引
oracle 访问对象有时候会有一个以上的索引选择。因此应当检查当前查询对象上的每一个索引以确保oracle使用了最佳索引。
物化聚合运算以静态化表统计
oracle 10g的特性之一sql access advisor 会给出索引建议以及物化视图的建议。物化视图可以预连接表和预摘要表数据。(译者
按，即oracle可以根据特定的更新方式来提前更新物化视图中的数据，而在查询时仅仅查询物化视图即可得到最终所需的统计数据
结果。物化视图实际上是一张实体表)
以上这些概括了sql tuning的目标。然而看是简单，调整起来并不容易，因为这需要对oracle sql内部有一个彻底的了解。接下来让我们从
整体上来认识 oracle sql 优化。
2、oracle sql 优化器
oracle dba首先要查看的是当前数据库缺省的优化器模式。oracle初始化参数提供很多基于成本优化的优化器模式以及之前废弃的基于规则
的优化器模式(或hint)供选择。基于成本的优化器主要依赖于表对象使用analyze命令收集的统计信息。oracle根据表上的统计信息得以决定
并为当前的sql生成最高效的执行计划。需要注意的是在一些场合基于成本优化器可能会做出不正确的决定。基于成本的优化器在不断的改进，
但是依然有很多场合使用基于规则的优化器能够使得查询更高效。
在oracle 10g之前，oracle 缺省的优化器模式是choose模式。在该模式下，如果表对象上缺乏统计信息则此时oracle使用基于规则的优化
器；如果统计信息存在则使用基于成本的优化器。使用choose模式存在的隐患即是对一些复杂得查询有些对象上有统计信息，而另一些对象
缺乏统计信息。
在oracle 10g开始，缺省的优化器模式是 all_rows，这有助于全表扫描优于索引扫描。all_rows优化器模式被设计成最小化计算资源且有
助于全表扫描。索引扫描(first_rows_n)增加了额外的i/o开销。但是他们能更快地返回数据。
因此，大多数oltp系统选择first_rows，first_rows_100 或者 first_rows_10以使得oracle使用索引扫描来减少读块数量。
注意：从oracle 9i r2开始，oracle 性能调整指导指出了first_rows 优化器模式已经被废弃，且使用first_rows_n代替
当仅有一些表包含cbo统计信息，而另一些缺乏统计信息时，oracle使用基于成本的优化模式来预估其他表在运行时的统计信息(即动态采样
)，这在很大程度上影响单个查询性能下降。
总之，oracle 数据库管理员应当总是将尝试改变优化器模式作为sql tuning的第一步。oracle sql tuning的首要原则是避免可怕的全表扫
描。一个特性之一是一个非高效的sql语句为提高查询性能使用所有的索引此仍然为一个失败的sql语句。
当然，有些时候使用全表扫描是合适的，尤其是在做聚合操作象sum，avg等操作，因为为了获得结果，表上的绝大部分数据行必须被读入到
缓存。sql tuning 高手应当合理的评估每一个全表扫描并要核实使用索引能否提高性能。
在大多数oracle 系统，sql语句检索的仅仅是表上数据一个子集。oracle 优化器会检查使用索引是否会导致更多的i/o。然而，如果构建了
一个低效的查询，基于成本的优化器难以选择最佳的数据访问路径，转而倾向于使用全表扫描。故oracle数据库管理员应当总是审查那些走
全表扫描的sql语句。
更多有关全表扫描的问题，，以及选择正确的优化模式请 ：oracle tuning: the definitive reference