sql调优(数据库性能80%问题)：
1 减少响应时间
2 减少资源的使用

找出有问题的sql
自动：addm,顶端sql
手动：v$视图，statspack
执行改变：
sql语句的结构
索引访问结构

驱动表有最好的过滤器
少量行数返回到下一个步骤
视图被有效的利用
每个表是被高效地访问
检查sql语句中的属性和表中的行数
全表扫描并不意味着效率低下。

避免在where 字句中转化column
避免mixed-mode的表达以及提防隐式类型转换
为特殊任务编写单独的sql语句和适当的使用sql建构。
使用exists或in为子查询的要求。
根据提示谨慎改变访问路径和连接顺序。

移除不必要的索引，以加快DML
索引的关键性能访问通道
在现有的索引中重新排列columns
新增columns到索引中，以改善选择性
基于使用类型创建适当的索引：
考虑索引组织表

简单的设计
数据建模
表和索引（表结构设计是最好的优化方法,最重要的优化是设计）
使用视图
写有效的sql
游标共享
使用棒定变量
sql与pl/sql对应
动态sql

数据地点查询优化统计表
统计表：存储在数据字典表，数据的陈述必须真实
收集使用：dbms_stats包，动态取样。

可以使用以下的初始化参数控制优化行为（使用其默认设置）：
cursor_sharing
db_file_multiblock_read_count
optimizer_index_caching
optimizer_index_cost_adj
optimizer_mode
pga_aggregate_target

所考虑的优化因数是：
访问通道：
join顺序：
join方法：

full-table scans:表大表小。2万数据量
row id scans:
index scans:
cluster scans:
hash scans:

全表扫描什么时候用？
缺乏索引，大量的数据(4%)，小表

1 产生连接顺序的列表
nested loop joins（连个小表关联,适合小表）:
两个表中其中的一个作为外表被定义（或驱动表）
另一个表叫做内部表
外部表的每一个行，在内部表中所有匹配的行被找回。

use_nl(table1 table2) hint 被使用

什么时候用hash joins?
大量的数据需要被加入
大部分表需要被加入
使用use_hash hint.

sort_merge join:不大不小的表，介于nested loop joins 和 hash_join之间

什么时候sort_merge joins被使用：
连接条件不是一个同等连接
排序对于其他操作是必须的

[@more@]

ITPub博客

sql tuning

最新文章