atistics;
SELECT *
FROM (SELECT * FROM t_1
UNION ALL
SELECT * FROM t_2) aa
WHERE aa.table_name LIKE 'Z%'; ---- Full Table Scans
SELECT /*+ index(AA.t_1 idx_t_1) index(AA.t_2 idx_t_2)*/ *
FROM (SELECT * FROM t_1
UNION ALL
SELECT * FROM t_2) AA
WHERE AA.table_name LIKE 'Z%'; ---- Index Scans
贴上执行图：
4.索引及应用实例
4.1什么是索引
*
Oracle的索引是一种自平衡的B*Tree存储结构，其基本存储单位为数据块，称之为节点，共有三种类型的节点：根（root）节点，分枝（Branch）节点，叶（leaf）节点。 *分枝节点存储{索引值，键值对应下一级节点块地址，lmc指针} *叶节点存储{索引值及其rowid，当前节点的前后节点的数据块地址}
所有叶节点上的两个指针形成一个双向链表，在这个双向链表上的所有索引值，从小到大排列，而对于倒序desc索引，则是从大到小排列
B*TREE索引图：
4.2索引分类
逻辑上：
Single column 单列索引
Concatenated 多列索引
Unique 唯一索引
Non-Unique 非唯一索引
Function-based函数索引
Domain 域索引
物理上：
Partitioned 分区索引
Non-Partitioned 非分区索引
B*tree：
Normal 正常型B树
ReverseKey 反转型B树
Bitmap 位图索引
4.3什么时候使用索引
*如果要检索全表，不必要建索引，因为索引会带来额外的IO操作。 *如果检索的记录数占全部表记录的10%以下可以考虑建索引(大表)。 *表之间的关联字段可以考虑建索引，特别是一张大表和一张小表的关联。 *B*Tree索引适合于大量的增、删、改（OLTP）；
不适合用包含OR操作符的查询；一般不适用NULL判断；
适合
高基数的列（重复值少） *Bitmap索引适合于决策支持
系统OLAP；
做UPDATE代价比较高；会锁块；
非常适合OR操作符的查询；
适合
低基数的列（比如，只有Y和N两种值） ； *Reverse索引反转了b*tree索引码中的字节，是索引条目分配更均匀，多用于并行服务器环境下，用于减少索引叶的竞争。 索引是’双刃剑’，在查询与DML之间寻求平衡
4.4改写SQL使用索引
*普通索引列 a is not null 按逻辑改为a>0或a>''
*like操作改写
*能用union all绝不用union，除非要去重
*in操作虽然简单易懂，但oracle内部会转换为表连接查询，使用in会多一步转换操作，所以建议使用表关联查询 *not in 强烈建议使用not exists或（外连接+判断为空） *<>（不等于）操作不走索引，推荐a<>0改为(a>0 ora<0) a<>’’改为a>’’ *提防隐式类型转换， oracle内部处理a=0与a=‘0’是完全不同的，甚至会导致不走索引
4.5索引应用
例1.用合适的索引来避免不必要的全表扫
如果要在索引列查询is not null条件，建议列加上is not null约束，默认值约束，
然而确实由于某种原因索引列设计为null，还想通过is null条件走索引，该如何是好呢？请看
drop table t_tab1;
create table t_tab1 as
SELECT t.owner,
t.object_name,
t.object_type,
t.created,
t.last_ddl_time
FROM dba_objects t;
analyze table t_tab1 compute statistics;
create index idx01_t_tab1 on t_tab1(last_ddl_time);--普通索引
set autotrace trace;
SELECT * FROM t_tab1 t where t.last_ddl_time is null; 执行计划如下图：
如上情况调整为复合索引
drop index idx01_t_tab1;
create index idx01_t_tab1 on t_tab1(last_ddl_time,1);--加了个常量
set autotrace trace;
SELECT * FROM t_tab1 t where t.last_ddl_time is null;
执行计划如下图：
例2：用合适的函数索引来避免看似无法避免的全表扫描
drop table t_tab1 purge;
create table t_tab1 as
SELECT t.owner,
t.object_name,
t.object_type,
t.OBJECT_ID,
t.created,
t.last_ddl_time
FROM dba_objects t;
CREATE INDEX IDX01_T_TAB1 ON T_TAB1(object_name);
analyze table t_tab1 compute statistics;
set autot trace
SELECT * FROM t_tab1 t where t.object_name like '%20121231';
执行计划如下：
改进索引，此处使用反转函数索引，此外经常用到的函数索引还有，instr(),substr()等
drop index IDX01_T_TAB1;
CREATE INDEX IDX02_T_TAB1 ON T_TAB1(reverse(object_name));
analyze table t_tab1 compute statistics;
SELECT * FROM t_tab1 t where reverse(t.object_name) like reverse('%20121231');
执行计划如下：
5.其他优化技术及应用
5.1其他优化技术及思路
并行技术，并行执行目标SQL语句，这实际上是以额外的资源消耗来换取执行时间的缩短，很多情况下使用并行是针对某些SQL的唯一优化手段。
使用shell调度或其他调度工具。
SQL语句级别的并行：/*+parallel*/
/*+ parallel(table_name 4)*/
表压缩技术
compress
NOLOGGING
减少日志
Partition技术
分而治之
中间表/临时表事务分解思路
‘大事化小’
求平衡
CPU，Memory很强大，IO存在瓶颈（最普遍的情况）
使用新特性
insertall 啦 使用listagg()比wm_concat()快大概50倍、row_number()等分析函数
软硬件资源合理搭配
黔驴技穷，要求加硬件资源？ Boss会对你说，找会计去吧，提前给你开工资 ……
5.2 SQL优化总结
SQL的优化的手段是五花八门、不一而足的，包括但不限于如下措施：
*如果是统计信息不准或是因为CBO计算某些SQL的执行路径（Access Path）的成本所用公式的先天不足而导致的SQL性能问题，
我们可以通过重新收集统计