1.绑定变量
在oracle 中，对于一个提交的sql语句,存在两种可选的解析过程, 一种叫做硬解析,一种叫做软解析.
一个硬解析需要经解析,制定执行路径,优化访问计划等许多的步骤.硬解释不仅仅耗费大量的cpu，更重要的是会占据重要的们闩（latch）资源，严重的影响系统的规模的扩大（即限制了系统的并发行）， 而且引起的问题不能通过增加内存条和cpu的数量来解决。之所以这样是因为门闩是为了顺序访问以及修改一些内存区域而设置的，这些内存区域是不能被同时修改。当一个sql语句提交后，oracle会首先检查一下共享缓冲池（shared pool）里有没有与之完全相同的语句，如果有的话只须执行软分析即可，否则就得进行硬分析。
而唯一使得oracle 能够重复利用执行计划的方法就是采用绑定变量。绑定变量的实质就是用于替代sql语句中的常量的替代变量。绑定变量能够使得每次提交的sql语句都完全一样。
普通sql语句：
SELECT fname, lname, pcode FROM cust WHERE id = 674;
SELECT fname, lname, pcode FROM cust WHERE id = 234;
SELECT fname, lname, pcode FROM cust WHERE id = 332;
含绑定变量的sql 语句：
SELECT fname, lname, pcode FROM cust WHERE id = :cust_no;
Sql*plus 中使用绑定变量：
sql> variable x number;
sql> exec :x := 123;
sql> SELECT fname, lname, pcode FROM cust WHERE id =:x;
pl/sql
pl/sql很多时候都会自动绑定变量而无需编程人员操心，即很多你写得sql语句都会自动利用绑定变量，如下例所示：
create or replace procedure dsal(p_empno in number)
as
begin
update emp
set sal=sal*2
where empno = p_empno;
commit;
end;
/
也许此时你会想要利用绑定变量来替代p_empno,但是这是完全没有必要的，因为在pl/sql中，引用变量即是引用绑定变量。
但是在pl/sql中动态sql并不是这样。
在vb，java以及其他应用程序中都得显式地利用绑定变量。
对于绑定变量的支持不仅仅限于oracle,其他RDBMS向SQLＳＥＲＶＥＲ也支持这一特性。
但是并不是任何情况下都需要使用绑定变量， 下面是两种例外情况：
１．对于隔相当一段时间才执行一次的ｓｑｌ语句，这是利用绑定变量的好处会被不能有效利用优化器而抵消
２．数据仓库的情况下。
在ORACLE中，使用绑定变量，可以降低硬解析，通常可以提高系统的性能（注意，是通常，不是任何情况下）。
以表tabletest为例，我们来看看如何使用绑定变量，tabletest的表结构为
field1 number(10)
field2 number(10)
field3 number(10)
field4 number(10)
field5 number(10)
绑定变量可以理解为一个占位符 ,例如：
declare
i number;
j number;
sqlstr varchar2(200);
begin
i:=1;
j:=2;
sqlstr:='insert into 测试表 (field1,field2,field3,field4,field5) values(:x,:x,:y,:x,:x)';
execute immediate sqlstr using i,i,j,i,i;
end;
这样的一段代码中，使用i,i,j,i,i来对应:x,:x,:y,:x,:x。这段代码是正确的，但如果以为sqlstr中只有:x,:y这两个绑定变量，而把语句execute immediate sqlstr using i,i,j,i,i;改为execute immediate sqlstr using i,j;就会在运行中出现绑定变量数量不够的错误。
上面的正确代码执行完后，插入的记录从field1到field5的数据应该是1,1,2,1,1。
如果我们把execute immediate sqlstr using i,i,j,i,i;改成execute immediate sqlstr using i,j,j,i,i;执行之后，察看插入的记录，就会发现插入的记录是1,2,2,1,1
从上面可以看出，绑定变量只是起到占位的作用，同名的绑定变量并不意味着在它们是同样的，在传递时要考虑的是传递的值与绑定变量出现顺序的对位，而不是绑定变量的名称。
ORACLE系统本身是能够对变量做绑定的，例如下面的代码：
declare
i number；
begin
for i in 1..1000 loop
insert into 测试表 (i,i+1,i*1,i*2,i-1)
end loop;
end;
这段代码是不需要使用绑定变量的方法来提高效率的，ORACLE会自动将其中的变量绑定。
我们可以这样理解：这段代码执行了1000次的 insert into 测试表 (i,i+1,i*1,i*2,i-1) 语句，每次发出去的语句都是一样的。
如果把这段代码改成如下：
declare
i number；
sqlstr varchar2(200);
begin
for i in 1..1000 loop
sqlstr:='insert into 测试表 ('||to_char(i)||','||to_char(i)||'+1,'||to_char(i)||'*1,'||to_char(i)||'*2,'||to_char(i)||'-1) ';
execute immediate sqlstr;
end loop;
end;
这段代码同样是执行了1000条insert语句，但是每一条语句都是不同的，因此ORACLE会把每条语句硬解析一次，其效率就比前面那段就低得多了。如果要提高效率，不妨使用绑定变量将循环中的语句改为
sqlstr:='insert into 测试表 (:i,:i+1,:i*1,:i*2,:i-1) ';
execute immediate sqlstr using i,i,i,i,i;
这样执行的效率就高得多了。
我曾试着使用绑定变量来代替表名、过程名、字段名等，结果是语句错误，结论就是绑定变量不能当作嵌入的字符串来使用，只能当作语句中的变量来用。
从效率来看，由于oracle10G放弃了RBO，全面引入CBO，因此，在10G中使用绑定变量效率的提升比9i中更为明显。
最后，前面说到绑定变量是在通常情况下能提升效率，那哪些是不通常的情况呢？
答案是：在字段(包括字段集)建有索引，且字段(集)的集的势非常大（也就是有个值在字段中出现的比例特别的大）的情况下，使用绑定变量可能会导致查询计划错误，因而会使查询效率非常低。这种情况最好不要使用绑定变量。
SQL 解析过程
我们都知道在Oracle中每条SQL语句在执行之前都需要经过解析，这里面又分为软解析和硬解析。在Oracle中存在两种类型的SQL语句，一类为 DDL语句(数据定义语言)，他们是从来不会共享使用的，也就是每次执行都需要进行硬解析。还有一类就是DML语句(数据操纵语言)，他们会根据情况选择要么进行硬解析，要么进行软解析。
DML:INSERT,UPDATE,DELETE,SELECT
DDL:CREATE,DROP,ALTER
一. SQL 解析过程
Oracle对此SQL将进行几个步骤的处理过程：
1、语法检查(syntax check): 检查此sql的拼写是否语法。
2、语义检查(semantic check): 诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。
3、对sql语句进行解析(prase): 利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(execution plan)。
4、执行sql，返回结果(execute and return)
二． 解析过程详解
2.1 语法检测
判断一条SQL语句的语法是否符合SQL的规范，比如执行：
SQL> selet * from emp;
我们就可以看出由于Select关键字少了一个“c”，这条语句就无法通过语法检验的步骤了。
2.2 语义检查
语法正确的SQL语句在解析的第二个步骤就是判断该SQL语句所访问的表及列是否准确？用户是否有权限访问或更改相应的表或列？ 比如如下语句：
SQL> select * from emp;
select * from emp
*
ERROR at line 1:
ORA-00942: table or view does not exist
由于查询用户没有可供访问的emp对象，因此该SQL语句无法通过语义检查。
2.3 解析(Parse)
2.3.1 Parse主要分为三种：
1、Hard Parse (硬解析)
2、Soft Parse (软解析)
3、Soft Soft Parse(好像有些资料中并没有将这个算在其中)
Hard Parse： 就是上面提到的对提交的Sql完全重新从头进行解析(当在Shared Pool中找不到时候将会进行此操作)，总共有一下5个执行步骤：
1：语法分析
2：权限与对象检查
3： 在共享池中检查是否有完全相同的之前完全解析好的. 如果存在，直接跳过4和5，运行Sql, 此时算soft parse.
4：选择执行计划
5：产生执行计划
注：创建解析树、生成执行计划对于sql的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。这就是在很多项目中，倡导开发设计人员对功能相同的代码要努力保持代码的一致性，以及要在程序中多使用绑定变量的原因。
Soft Parse： 就如果是在Shared Pool中找到了与之完全相同的Sql解析好的结果后会跳过Hard Parse中的后面的两个步骤。
Soft Soft Parse： 实际上是当设置了session_cursor_cache这个参数之后，Cursor被直接Cache在当前Session的PGA中的，在解析的时候只需要对其语法分析、权限对象分析之后就可以转到PGA中查找了，如果发现完全相同的Cursor，就可以直接去取结果了，也就就是实现了 Soft Soft Parse.
2.3.2 解析的步骤可以分为两个步骤：
1) 验证SQL语句是否完全一致。
在这个步骤中，Oracle将会对传递进来的SQL语句使用HASH函数运算得出HASH值，再与共享池中现有语句的HASH值进行比较看是否一一对应。现有数据库中SQL语句的HASH值我们可以通过访问v$sql、v$sqlarea、v$sqltext等数据字典中的HASH_VALUE列查询得出。
如果SQL语句的HASH值一致，那么ORACLE事实上还需要对SQL语句的语义进行再次检测，以决定是否一致。那么为什么Oracle需要再次对语句文本进行检测呢？不是SQL语句的HASH值已经对应上了？事实上就算是SQL语句的HASH值已经对应上了，并不能说明这两条SQL语句就已经可以共享了。
例如：假如用户SYS有自己的一张表EMP，他要执行查询语句：select * from emp; 用户SYSTEM也有一张EMP表，同样要查询select * from emp；这样他们两条语句在文本上是一模一样的，他们的HASH值也会一样，但是由于涉及到查询的相关表不一样，他们事实上是无法共享的.
SQL> conn / as sysdba
已连接。
SQL> show user
USER 为 "SYS"
SQL> create table emp ( x int ) ;
表已创建。
SQL> select * from emp;
未选定行
SQL> conn system/admin;
已连接。
SQL> create table emp ( x int );
表已创建。
SQL> select * from emp;
未选定行
SQL> select address,hash_value, executions, sql_text from v$sql where upper(sql_text) like 'SELECT * FROM EMP%';
ADDRESS HASH_VALUE EXECUTIONS SQL_TEXT
----------------------- ---------------------------------------------------------
2769AE64 1745700775 1 select * from emp
2769AE64 1745700775 1 select * from emp
2 rows selected.
从结果可以看到这2个查询的语句文本和HASH值都是一样的，但是由于查询的对象不同，是无法共享的，不同情况的语句还是需要硬解析的。因此在检查共享池共同SQL语句的时候，是需要根据具体情况而定的。
可以进一步查询v$sql_shared_cursor以得知SQL为何不能共享的原因：
SQL>select address,auth_check_mismatch,translation_mismatch,optimizer_mismatch
from v$sql_shared_cursor where address in (
select address from v$sql where upper(sql_text) like 'SELECT * FROM EMP%' )
ADDRESS A T O
---------------- ----- -- --
2769AE64 N N N
2769AE64 Y Y N
TRANSLATION_MISMATCH 表示SQL游标涉及到的数据对象是不同的；
AUTH_CHECK_MISMATCH 表示对同样一条SQL语句转换是不匹配的。
optimizer_mismatch 表示会话的优化器环境是不同的。
2) 验证SQL语句执行环境是否相同
比如同样一条SQL语句，一个查询会话加了/*+ first_rows */的HINT，另外一个用户加/*+ all_rows */的HINT，他们就会产生不同的执行计划，尽管他们是查询同样的数据。
通过如上检查以后，如果SQL语句是一致的，那么就会重用原有SQL语句的执行计划和优化方案，也就是我们通常所说的软解析。如果SQL语句没有找到同样的副本，那么就需要进行硬解析了。
Oracle根据提交的SQL语句再查询相应的数据对象是否有统计信息。如果有统计信息的话，那么CBO将会使用这些统计信息产生所有可能的执行计划(可能多达成千上万个)和相应的Cost，最终选择Cost最低的那个执行计划。如果查询的数据对象无统计信息，则按RBO的默认规则选择相应的执行计划。这个步骤也是解析中最耗费资源的，因此我们应该极力避免硬解析的产生。至此，解析的步骤已经全部完成，Oracle将会根据解析产生的执行计划执行SQL语句和提取相应的数据。
2.4 执行sql，返回结果(execute and return)
三. 绑定变量
使用了Bind Var能提高性能主要是因为这样做可以尽量避免不必要的硬分析(Hard Parse)而节约了时间，同时节约了大量的CPU资源。
当一个Client提交一条Sql给Oracle后，Oracle 首先会对其进行解析(Parse)，然后将解析结果提交给优化器(Optimiser)来进行优化而取得Oracle认为的最优的Query Plan，然后再按照这个最优的Plan来执行这个Sql语句(当然在这之中如果只需要软解析的话会少部分步骤)。
但是，当Oracle接到 Client提交的Sql后会首先在共享池(Shared Pool)里面去查找是否有之前已经解析好的与刚接到的这一个Sql完全相同的Sql(注意这里说的是完全相同，既要求语句上的字符级别的完全相同，又要求涉及的对象也必须完全相同)。当发现有相同的以后解析器就不再对新的Sql在此解析而直接用之前解析好的结果了。这里就节约了解析时间以及解析时候消耗的CPU资源。尤其是在OLTP中运行着的大量的短小Sql，效果就会比较明显了。因为一条两条Sql的时间可能不会有多少感觉，但是当量大了以后就会有比较明显的感觉了。
