用了几年的Oracle,对一些日常的开发和优化技术已经所有耳闻,简单罗列一些
1:单表的查询性能
要看数据的量,查询条件,是否命中主键、索引;如果数据量在几百万,几乎不需要考虑;
如果几千万到亿的数据量,如果不走索引,查询的性能可想而知;
当然查询记录的数据量跟整表的数据量对比,如果查询的结果跟总量对比比较大时,避免全部扫描
如果几乎相当,全部扫描未必是效率低下。
2:多表的查询性能
需要考虑更多因素
全部扫描访问方式【全表扫描,或者快速全索引扫描】
索引扫描访问方式
关注:oracle常用的索引类型
B树索引:适合数据重复率低的列
位图索引:适合数据重复率高的列
索引扫描机制:
索引范围扫描,索引唯一扫描,索引全扫描,索引跳跃扫描,索引快速全扫描。
当然索引的扫描离不开索引统计信息:聚簇因子(Clustering factor)的统计信息用来帮助优化器生成使用索引的成本信息。
需要识别索引扫描的场景:
索引唯一扫描:当谓词中包含使用UNIQUE或PRIMARY KEY索引作为条件的时候,就会选用索引唯一扫描。
索引范围扫描:当谓词中返回一定范围数据的条件时,就会选用索引范围扫描---比如,LIKE,BETWEEN
索引全扫描:当没有谓词但是所需获取列的列表可以通过其中一列的索引来获得,谓词中包含一个位于索引中非引导列上的条件。
索引跳跃扫描:当谓词中包含位于索引中非引导列上的条件,并且引导列的值唯一的时候,会选择索引跳跃扫描。
多个表之间的联接方法,优化器确定如何将多个表连接起来的最佳方法以及最恰当的顺序。
多个表之间的查询,如果没有指定关联关系,会隐含式地将多个表之间的数据一一联接,称为笛卡儿联结。
多表连接的方式包括:
嵌套循环联结:使用一次访问运算所得到的结构集中的每一行来于另一个表进行对碰;如果结构集的大小是有限的,并且在用来联结的列上建有索引的话,联结的效率比较高。
排序-合并联结:独立地读取需要连接的两张表,对每张表中的数据行(where字句中的数据行)按照联结键进行排序,然后对排序后的数据行进行合并。
排序开支比较大,但是合并的过程较快。
嵌套联结:
笛卡尔联结:将两个表的结果一一相乘。
外联结:返回一张表的所有行以及另一张联结表中满足联结条件的行数据,通过(+)
3:理解SQL的本质
关于集合的,并非类似编程语言是面向过程的
比如:
Union:为将两个集合的结构合计起来,但是会去掉重复的行
Union All:则返回所有行,包括重复的行记录数据
当然Oracle 10G,可以通过HASH Unique运算符来去重重复行
Minus:通常替代NOT Exists,反联结
Intersect:通常替代EXISTS(半联结),获取两个集合中都存在的数据行集。
4:关注SQL的执行计划
从前面的索引和联结方式,以及SQL的集合的本质,如果想深入优化数据查询的性能,必须关注执行计划
PL/SQL Developer可以清楚的分析执行计划,或者通过SQLPlus来获取执行计划,当然运行前的执行计划,跟运行后的实际执行情况,会有略微区别。
需要关注:
解释计划:通过Explain plan用来显示优化器为SQL语句所选择的执行计划,一个预期执行计划
包括SQL所引用的表、
访问表的方法
对每一对需要联结的数据源所用的联结方法
按次序列出的所有需要完成的运算
计划中各步骤的谓词信息列表
对于每个运算,估计出该步骤所要操作的数据行数和字节数
对于每个运算,计算出成本值
如果适用,所访问的分区信息
如果适用,并行执行的相关信息
可以通过explain plan for (sql).
对应的结果保存在PLAN_TABLE中
dbms_xplan.display函数
一个问题不可忽视:解释计划基于适用环境,跟最终运行环境可能存在差异;
不考虑绑定变量的数据类型
不“窥视”绑定变量的值
所以可能导致,解释计划跟最终的执行计划有不同。
执行计划
学会阅读的技巧
以及获取最种的实际的执行计划
通过V$SQL_PLAN来查看计划运算,跟PLAN_TABLE类似,但是包括一些如何在库高速缓存中定位并找出当前所执行语句的列
ADDRESS
HASH_VALUE
SQL_ID
PLAN_HASH_VALUE
CHILD_ADDRESS
CHILD_NUMBER
DBMS_XPLAN
实例:select /*recentsql */ sql_id,child_number,hash_value,address,executions,sql_text from v$sql where parsing_user_id=...
查看相关执行计划
select /*+ gather_plan_statistics*/ empno,ename from scott.emp where ename='Test';
如果有兴趣,可以深入分析DBMS_XPLAN
更多精彩会进一步补充......