ORACLE 4 SQL语句解析

Oracle 的硬解析和软解析

提到软解析(soft parse)和硬解析(hard parse)，就不能不说一下Oracle 对sql的处理过程。当你发出一条sql 语句交付Oracle，在执行和获取结果前，Oracle对此sql 将进行几个步骤的处理过程：

1、语法检查(syntax check)

检查此sql 的拼写是否语法。

2、语义检查(semantic check)

诸如检查sql 语句中的访问对象是否存在及该用户是否具备相应的权限。

3、对sql 语句进行解析(parse)

利用内部算法对sql 进行解析，生成解析树(parse tree)及执行计划(execution plan)。

4、执行sql，返回结果(execute and return)

其中，软、硬解析就发生在第三个过程里。

Oracle 利用内部的hash 算法来取得该sql 的hash 值，然后在library cache 里查找是否存在该hash 值；假设存在，则将此sql 与cache 中的进行比较；假设“相同”，就将利用已有的解析树与执行计划，而省略了优化器的相关工作。这也就是软解析的过程。诚然，如果上面的2 个假设中任有一个不成立，那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析。

创建解析树、生成执行计划对于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会将第一次编译后的查询方案(在第一次编译执行之后已经储存在共享池中)用来进行下一次的查询。

代码块一：

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;
/
81.62seconds ...

代码块二：
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;
/
.28seconds ...

在代码块二中使用了变量X，将i的值赋给了X，这样一来，ORACLE在执行的时候只需要编译一次，其他999次都是从共享池中使用查询方案，查询速度较代码块一快将近300倍。