模拟示例1：
已知emp，eid是主键，age上面建立索引
清空数据库缓冲
call sp_clear_plan_cache();
CREATE table aa as SELECT DISTINCT(SAL) FROM EMP where 1=0;
执行如下sql，没有用到变量，执行时间628毫秒
BEGIN
for i in 1 ..1000 loop
EXECUTE IMMEDIATE 'INSERT INTO AA SELECT DISTINCT(SAL) FROM EMP WHERE EID= '||I||' ORDER by sal';
end loop;
end;
查询执行计划缓存，可以看到每个sql都生成一个执行计划，查询优化器认为是不同的SQL语句，需要解析1000次
select CACHE_ITEM,SQLSTR from v$cachepln where upper(SQLSTR) like '%EMP%'
清空数据库缓存，使用变量之后38毫秒就可以执行成功
BEGIN
for i in 1 ..1000 loop
INSERT INTO AA SELECT DISTINCT(SAL) FROM EMP WHERE eid= i ORDER by sal;
end loop;
end;
查询执行计划缓存，只生成一个执行计划。
绑定变量优点：使用变量后，相同的查询语句如果只是赋值不同，可以重复使用第一次的执行计划，做到一次解析，多次复用的效果，避免硬解析提升执行效率
模拟示例2
清空缓存之后，执行如下sql，执行时间937毫秒
BEGIN
for i in 1 ..1000 loop
EXECUTE IMMEDIATE 'INSERT INTO AA SELECT DISTINCT(SAL) FROM EMP WHERE AGE= '||I||' ORDER by sal';
end loop;
end;
优化器也生成了不同的执行计划
清空缓存，使用变量，执行时间为7s，
BEGIN
for i in 1 ..1000 loop
INSERT INTO AA SELECT DISTINCT(SAL) FROM EMP WHERE age= i ORDER by sal;
end loop;
end;
查询执行计划，也只生成了一个执行计划
两个示例，同样使用了变量，都减少了硬件解析，为什么一个使用变量能提升执行效率。另外一个使用变量之后，执行效率降低了很多
原因排查：
使用trace plndump获取缓存执行计划内容 注意新版本plndump trace不再支持指定操作系统路径，默认文件生产在trace目录下）
alter session set events 'immediate trace name plndump level 140631589976504,dump_file ''/data/testcahe.trc''';
alter session set events 'immediate trace name plndump level 140631589976504,dump_file ''dmtest1.trc''';
查询 trace路径：
获取的缓存执行计划如下：可以看到执行计划是走了索引的，但回表次数多
看下age的数据分布情况，可以看到分布非常不均衡
当单独执行当age=1的执行时间如下，执行计划走全表扫描
而dump出来的执行计划走了索引，测试当age=1时走索引的执行时间
绑定变量缺点：
绑定变量被使用时，查询优化器会忽略其具体值，因此其预估的准确性远不如使用字面量值真实，尤其是在表存在数据倾斜(表上的数据非均匀分布)的列上会提供错误的执行计划。导致后面的执行计划都不是最优。