Oracle中的硬解析和软解析

在执行和获取结果前，数据库系统对此sql将进行几个步骤的处理过程： 
1、语法检查(syntax check) 
检查此sql的拼写是否语法。 
2、语义检查(semantic check) 
诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。 
3、对sql语句进行解析(prase) 
利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(execution plan)。 
4、执行sql，返回结果(execute and return) 
其中，软、硬解析就发生在第三个过程里。 
数据库利用内部的hash算法来取得该sql的hash值，然后在library cache里查找是否存在该hash值。假设存在，则将此sql与cache中的进行比较。假设“相同”，就将利用已有的解析树与执行计划，而省略了优化器的相关工作。这也就是软解析的过程。 
如果上面的2个假设中任有一个不成立，那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析

可以这样形象理解：
软解析在缓冲区里找到相同或相似的SQL语句，可以直接利用，不用重新进行分析生成执行计划了。
硬解析则相反。

创建解析树、生成执行计划对于sql的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。

这就是在很多项目中，倡导开发设计人员对功能相同的代码要努力保持代码的一致性，以及要在程序中多使用绑定变量的原因。

有如下两句查询语句：

1.SELECT * FROM EMP WHERE EMPNO = 123;

2.SELECT * FROM EMP WHERE EMPNO = :EMP_NO;

1句中查询员工编号是123的员工信息，ORACLE第一次经过分析编译后执行。但如果下次还要再查询编号为456和789的员工信息时，ORACLE将会再将这句SQL分析编译，然后再执行。

再看2句，首先定义变量EMP_NO，我们将123赋给变量，第一次的时候也是经过分析编译后再执行，但是到了接下来再想查询其他员工编号的信息时，ORACLE会将第一次编译后的查询方案(在第一次编译执行之后已经储存在共享池中)用来进行下一次的查询。

这就像JAVA，想想看，如果你用JAVA写了一个软件，给客户的是你写的JAVA代码，客户在每次使用的时候都耀编译代码，然后执行。这将会影响多大啊。

所以说，分析一个带有硬编码变量的语句(称为硬分析)要明显的比重用一个已经分析过的查询方案(软分析)要花费更长的时间和耗费更多的资源。

如果使用绑定变量，提交引用相同变量的完全相同的查询的人将会使用共享池中的编译方案，只需编译子例程一次，就可以重复使用。这样不仅可以使用较少的时间，而且可以减少锁存时间，降低锁存频率。这将会提高软件性能，大大提高可伸缩性。

下面的试验将更能说明这个道理：

代码
ALTER SYSTEM FLUSH SHARED_POOL;
SET SERVEROUTPUT ON;
SET TIMING ON;
DECLARE
          TYPE rc IS REF CURSOR;
          l_rc rc;
          l_dummy all_objects.object_name%TYPE;
          l_start NUMBER DEFAULT dbms_utility.get_time;
BEGIN
          FOR i IN 1 .. 1000 LOOP
          OPEN l_rc FOR 'select object_name from all_objects where object_id = '||i;
          FETCH l_rc INTO l_dummy;
          CLOSE l_rc;
          END LOOP;
          dbms_output.put_line(round((dbms_utility.get_time-l_start)/100,2)|| 'seconds ...');     
END;

PL/SQL 过程已成功完成。

已用时间:   00: 00: 53.05

上述代码使用动态SQL从ALL_OBJECTS表中查询单行。它用值1，2，3.......1000等硬编码产生1000条不同的查询进入WHERE子句，看看运行时间53秒。
再看下面代码：
代码
DECLARE
        TYPE rc IS REF CURSOR;
        l_rc rc;
        l_dummy all_objects.object_name%TYPE;
        l_start NUMBER DEFAULT dbms_utility.get_time;
BEGIN
        FOR i IN 1 .. 1000 LOOP
        OPEN l_rc FOR 'select object_name from all_objects where object_id = :x' USING i;
        FETCH l_rc INTO l_dummy;
        CLOSE l_rc;
        END LOOP;
        dbms_output.put_line(round((dbms_utility.get_time-l_start)/100,2)|| 'seconds ...'); 
END;

PL/SQL 过程已成功完成。
已用时间:   00: 00: 00.03

！!!!!!!    0.03秒，差距竟然这么大，回头看代码，第二次只是在循环体中使用了变量X，将i的值赋给了X，这样一来，ORACLE在执行的时候只需要编译一次，其他999次都是从共享池中使用查询方案，查询时间和速度当然更快了。
所以。从软件开发的一开始就要认识到绑定变量的重要性。 


我们都知道在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的时间可能不会有多少感觉，但是当量大了以后就会有比较明显的感觉了。

1. 认识绑定变量：
绑定变量是为了减少解析的，比如你有个语句这样
select aaa,bbb from ccc where ddd=eee;
如果经常通过改变eee这个谓词赋值来查询，像如下
select aaa,bbb from ccc where ddd=fff;
select aaa,bbb from ccc where ddd=ggg;
select aaa,bbb from ccc where ddd=hhh;
每条语句都要被数据库解析一次，这样比较浪费资源，如果把eee换成“:1”这样的绑定变量形式，无论ddd后面是什么值，都不需要重复解析

Java实现绑定变量的方法：
PreparedStatement pstmt = con.prepareStatement("UPDATE employees SET salay = ? WHERE id = ?");  
pstmt.setBigDecimal(1, 15.00);  
pstmt.setInt(2, 110592);   
/result statmement:   UPDATE employees SET salay = 15.00 WHERE id = 110592  
pstmt.executeQuery();  

假设要将id从1到10000的员工的工资都更新为150.00元，不使用绑定变量，则：
sql.executeQuery("UPDATE employees SET salay = 150.00 WHERE id = 1");  
sql.executeQuery("UPDATE employees SET salay = 150.00 WHERE id = 2");  
sql.executeQuery("UPDATE employees SET salay = 150.00 WHERE id = 3");  
sql.executeQuery("UPDATE employees SET salay = 150.00 WHERE id = 4");  
....  
sql.executeQuery("UPDATE employees SET salay = 150.00 WHERE id = 10000");  

使用绑定变量，则：
PreparedStatement pstmt;  
for (id = 1; id < 10000; id++)  
{  
  if (null == pstmt)  
    pstmt = con.prepareStatement("UPDATE employees SET salay = ? WHERE id = ?");  
    pstmt.setBigDecimal(1, 150.00);  
    pstmt.setInt(2, id);   
    pstmt.executeQuery();  
}  

二者区别在于，不用绑定变量，则相当于反复解析、执行了1w个sql语句。使用绑定变量，解析sql语句只用了一次，之后的9999次复用第一次生成的执行计划。显然，后者效率会更高一些。

2. 什么时候不应该/不必要使用绑定变量
a. 如果你用数据仓库，一条大查询一跑几个小时，根本没必要做绑定变量，因为解析的消耗微乎其微。
b. 变量对优化器产生执行计划有很重要的影响的时候：绑定变量被使用时，查询优化器会忽略其具体值，因此其预估的准确性远不如使用字面量值真实，尤其是在表存在数据倾斜(表上的数据非均匀分布)的列上会提供错误的执行计划。从而使得非高效的执行计划被使用。

3. 绑定变量在OceanBase中的实现
目前OceanBase中实现了绑定变量，目的主要是为了编程方便，而不是为了降低生成执行计划的代价。为什么呢？因为OceanBase中目前使用的是一种”静态执行计划“，无论什么Query，执行流程都一样。OB在前端代理ObConnector中实现绑定变量，将用户传入的变量进行to_string()操作，替代SQL语句中相应的部分，形成一个完整的SQL。然后这个SQL传递给MS，MS按照标准流程来解析和执行。相信不远的将来，OB将会实现真正意义上的绑定变量，让用户享受到绑定变量带来的好处。

4.使用绑定变量的好处
由上面的示例可知，在未使用绑定变量的情形下，不论是解析次数，闩使用的数量，队列，分配的内存，库缓存，行缓存远远高于绑定
变量的情况。因此尽可能的使用绑定变量避免硬解析产生所需的额外的系统资源。
绑定变量的优点
减少SQL语句的硬解析，从而减少因硬解析产生的额外开销(CPU,Shared pool,latch)。其次提高编程效率，减少数据库的访问次数。
绑定变量的缺点
 优化器就会忽略直方图的信息，在生成执行计划的时候可能不够优化。SQL优化相对比较困难

四、总结
 1.尽可能的避免硬解析，因为硬解析需要更多的CPU资源，闩等。
 2.cursor_sharing参数应权衡利弊，需要考虑使用similar与force带来的影响。
 3.尽可能的使用绑定变量来避免硬解析。