理解索引-常见问题分析
3、带通配符（%）的like语句 select * from employee where last_name like '%cliton%'; 由于通配符（%）在搜寻词首出现，所以数据库将不使用 last_name的索引。在很多情况下可能无法避免这种情况，但是一定要 心中有数，通配符如此使用会降低查询速度。 当通配符出现在字符串 其他位置时，优化器就能利用索引。在下面的查询中索引得到了使 用： select * from employee where last_name like 'c%';
Oracle数据库培训
高效率SQL语句基础
--张林
引言
一个高效率的数据库系统是从两个方面来评价的： 响应时间和吞吐量。 在应用系统开发阶段，由于开发库上的数据比较少，在SQL语句的 编写上感觉不出各种写法的性能差异，在将应用系统提交实际应用后， 随着数据库中数据的增加，系统的响应速度就会成为最需要解决的主 要问题之一。 缩短系统的响应时间，增加操作的并发度，可以提高系 统的吞吐量。 要缩短系统的响应时间，就需要可以高效率执行的SQL语句。
select * from employee where salary<>3000;
解决方法:不使用NOT，例：
select * from employee where salary<3000 or salary>3000;
这两种查询的结果一样，但是第二种查询会对salary列使用索引，
会更快些，而第一种查询则不会使用索引。
理解索引-常见问题分析
8、 组合索引（一） 在place，date，amount上建组合索引，前导列为place select count(*) from record where date > '19991201' and date < '1999 1214' and amount > 2000 （26秒） select date, sum(amount) from record group by date （27秒） select count(*) from record where date > '19990901' and place in ('BJ, 'SH') （< 1秒） 。 这是一个不合理的组合索引，因为它的前导列是place，第一和第 二条SQL没有引用place，因此也没有利用上索引。
理解索引-常见问题分析
注意： 索引并非越多越好，过多的索引会降低更新和插入操作的速度
优化器介绍
Oracle 的优化器有两种： RBO(Rule-Based Optimization): 基于规则的优化器 CBO(Cost-Based Optimization): 基于代价的优化器
从Oracle 10g开始，RBO 已经被弃用，但是我们依然可以通过Hint 方式来 使用它。
CBO的思路是让Oracle 获取所有执行计划相关的信息，通过对这些信息做 计算分析，最后得出一个代价最小的执行计划作为最终的执行计划。
下面是一个采用联接查询的SQL语句: select * from employee where first_name||’ ’||last_name =‘Bill Cliton’;
改进方法： select * from employee where first_name = ‘Bill’ and last_name = ‘Cliton’;
理解索引-常见问题分析
5、 NOT NOT可用来对任何逻辑运算符号取反，例： select * from employee where not (salary=3000); 要使用NOT，则应在取反的短语前面加上括号。 NOT运算符的以上形式比较少用，但是它会包含在另外一个逻辑 运算符中，这就是不等于”<>”运算符，如：
理解索引-常见问题分析
8、 组合索引（二） 合理的索引设计，要使每个SQL都可以利用索引，那么我们就需要 将date作为前导列，使三条语句性能达到最优。 select count(*) from record where date > '19991201' and date < '1999 1214' and amount > 2000(< 1秒) select date, sum(amount) from record group by date （11秒） select count(*) from record where date > '19990901' and place in ('BJ' ,'SH') （< 1秒）
select * from record where amount/30< 1000; 即： where子句中对列的任何操作结果都是在SQL运行时逐列计算 得到的，因此它不得不进行表搜索，而没有使用该列上面的索引。
理解索引-常见问题分析
7、 不可优化的where子句（二） 我们把上面的两条语句进行重写： select * from zk_kj_kpxx where nsrsbh like ‘000000%’;(495毫秒) select * from record where amount < 1000*30; 即：没有对列进行任何操作，结果在查询编译时就能得到，那么 就可以被 SQL优化器优化，使用索引，避免表搜索。 之前在网开系统的SQL语句优化时碰到过类似的情况，请大家多加 注意，尽量避免此类问题的发生。
理解索引-常见问题分析
7、 不可优化的where子句（三） 表stuff有200000行，id_no上有非群集索引，如下： select count(*) from stuff where id_no in('0','1') ; 分析： where条件中的‘in’在逻辑上相当于‘or’，所以语法分析器 会将in (‘0’,‘1’)转化为id_no =‘0’ or id_no=‘1’来执行。虽然CBO会选择最 优的执行计划，然而仍旧会出现没有利用id_no上索引的情况，导致查 询较慢，如果数据量非常大且对SQL语句的效率有较高的要求不妨考 虑使用简单的存储过程来实现相同的功能。
理解索引-常见（四） 小结： 1、任何对列的操作都将导致表扫描，它包括数据库函数、计算表 达式等等，查询时要尽可能将操作移至等号右边。 左右不重要，重要 的是表达式中是否包含列。 2、in、or子句常会使用工作表，使索引失效；如果不产生大量重 复值，可以考虑把子句拆开；拆开的子句中应该包含索引。 3、 要根据实际情况善于使用存储过程，它使SQL变得更加灵活和 高效。
理解索引-常见问题分析
4、 order by语句 order by语句决定了数据库如何将返回的查询结果排序。order by 语句对要排序的列没有什么特别的限制，也可以将函数加入列中（象 联接或者附加等）。任何在order by语句的非索引项或者有计算表达式 都将降低查询速度。 需要仔细检查order by语句以找出非索引项或者 表达式，它们会降低性能。 解决这个问题的办法就是重写order by语 句以使用索引，也可以为所使用的列建立另外一个索引，同时应绝对 避免在order by子句中使用表达式。
理解索引-常见问题分析
8、 组合索引（三） 小结： 1、有大量重复值、且经常有范围查询 ，如：（between, >,< ， >=,< =）和order by、group by发生的列，可考虑建立聚簇索引。 2、经常同时存取多列，且每列都含有重复值可考虑建立组合索引； 3、组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使 用最频繁的列。
优化器介绍
使用CBO 时，需要注意如下几个方面： 1、编写SQL语句时，不必考虑"FROM" 子句后面的表或视图的顺序和 "WHERE" 子句后面的条件顺序； 2、使用CBO 时，SQL语句 "FROM" 子句后面的表的个数不宜太多，因为 CBO在选择表连接顺序时，会对"FROM" 子句后面的表进行阶乘运算，选择最 好的一个连接顺序。 3、如果一个语句使用 RBO的执行计划确实比CBO 好，则可以通过hint机 制，强制使用RBO。 Hint机制可以参考这篇文章：/blog/1478465
理解索引-常见问题分析
2、列的连接 列被包含到表达式中导致不能使用索引。 对于有连接的列，即使
最后的联接值为一个静态值，优化器是不会使用索引的。 例： 假定有一个职工表(employee)，对于一个职工的姓和名分成两列存放 (FIRST_NAME)和(LAST_NAME)，现在要查询一个叫Bill Cliton的职工。
目录
一、优化器介绍 二、高效率SQL基础 三、oracle的执行计划 四、书写高效率SQL语句建议
优化器介绍
Oracle 数据库中优化器（Optimizer）是SQL分析和执行的优化工具，它负 责指定SQL的执行计划，也就是它负责保证SQL执行的效率最高，比如优化器 决定Oracle 以什么样的方式来访问数据，是全表扫描（Full Table Scan），索引 范围扫描（Index Range Scan）还是全索引快速扫描（INDEX Fast Full Scan： INDEX_FFS）;对于表关联查询，它负责确定表之间以一种什么方式来关联，比 如HASH_JOHN还是NESTED LOOPS 或者MERGE JOIN。 这些因素直接决定SQL的 执行效率，所以优化器是SQL 执行的核心，它做出的执行计划好坏，直接决定 着SQL的执行效率。
理解索引-常见问题分析
6、 IN和EXISTS(二) 使用IN子查询时，首先执行子查询，并将获得的结果列表存放在 在一个加了索引的临时表中。在执行子查询之前，系统先将主查询挂 起，待子查询执行完毕，存放在临时表中以后再执行主查询。 所以使 用EXISTS通常比使用IN查询速度快。 应尽可能使用NOT EXISTS来代替NOT IN，尽管二者都使用了NOT(不 能使用索引而降低速度)，但NOT EXISTS要比NOT IN查询效率高。