【转】sql解析步骤,硬解析和软解析
我们都知道在Oracle中每条SQL语句在执行之前都需要经过解析,这里面又分为软解析和硬解析。在Oracle中存在两种类型的SQL语句,一类为
DDL语句(数据定义语言),他们是从来不会共享使用的,也就是每次执行都需要进行硬解析。还有一类就是DML语句(数据操纵语言),他们会根据情况选择
要么进行硬解析,要么进行软解析。
DML:INSERT,UPDATE,DELETE,SELECT
DDL:CREATE,DROP,ALTER
SQL语句的解析步骤,当一条SQL语句从客户端进程传递到服务器端进程后,需要执行如下步骤:
1在共享池中搜索 SQL 语句的现有副本
2验证 SQL 语句的语法是否准确
3执行数据字典查找来验证表和列的定义
4获取对象的分析锁以便在语句的分析过程中对象的定义不会改变
5检查用户访问引用方案对象的权限
6确定语句的最佳执行计划
6语句和执行计划载入共享的 SQL 区
原来,我认为硬解析就是上面几个步骤。相对于硬解析,软解析的步骤就是上面第一步找到现有SQL语句的副本后,只需要验证用户是否有权限执行就是了,这样省略上面好几个步骤,相对硬解析来说性能开销就非常小了。
后来才知道上面的真正的解析步骤不是这样的。
事实上,在Oracle中SQL语句的解析步骤如下:
1、 语法检测。判断一条SQL语句的语法是否符合SQL的规范,比如执行:SQL> selet * from emp;我们就可以看出由于Select关键字少了一个“c”,这条语句就无法通过语法检验的步骤了。
2、 语义检查。语法正确的SQL语句在解析的第二个步骤就是判断该SQL语句所访问的表及列是否准确?用户是否有权限访问或更改相应的表或列?
比如如下语句:
SQL> select * from emp;
select * from emp
*
ERROR at line 1:
ORA-00942: table or view does not exist
由于查询用户没有可供访问的emp对象,因此该SQL语句无法通过语义检查。
3、 检查共享池中是否有相同的语句存在。假如执行的SQL语句已经在共享池中存在同样的副本,那么该SQL语句将会被软解析,也就是可以重用已解析过的语句的执行计划和优化方案,可以忽略语句解析过程中最耗费资源的步骤,这也是我们为什么一直强调避免硬解析的原因。
这个步骤又可以分为两个步骤:
(1、)验证SQL语句是否完全一致。
在
这个步骤中,Oracle将会对传递进来的SQL语句使用HASH函数运算得出HASH值,再与共享池中现有语句的HASH值进行比较看是否一一对应。现
有数据库中SQL语句的HASH值我们可
相关文档:
【1】
create procedure proc_pager1
( @pageIndex int, -- 要选择第X页的数据
@pageSize int -- 每页显示记录数
)
AS
BEGIN
declare @sqlStr varchar(500)
set @sqlStr='select top '+con ......
Microsoft Access 数据类型
数据类型
描述
存储
Text
用于文本或文本与数字的组合。最多 255 个字符。
Memo
Memo 用于更大数量的文本。最多存储 65,536 个字符。
注释:无法对 memo 字段进行排序。不过它们是可搜索的。
Byte
允许 0 到 255 的数字。
1 字节
Integer
允许介于 -32,768 到 32 ......
ORACLE SQL优化
(1) 选择最有效率的表名顺序(只在基于规则的优化器中有效):
ORACLE 的解析器按照从右到左的顺序处理from 子句中的表名,from 子句中写在最后的表
(基础表driving table)将被最先处理,在from 子句中包含多个表的情况下,你必须选择记
录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需 ......
C#中以windows验证方式连接SQL server数据库的类。很多人连接数据库时可能都是网上查了然后就连了,对于参数的含义倒是没怎么在意,偶也是(呵呵),当然我们都注重结果嘛,可是这样不容易记忆每次连的时候都是上网查,感觉挺不方便,所以索性查了一下。~~~Integrated Security=True;表示在连接数据库进行身份验证时用wind ......
说到软解析(soft prase
)和硬解析(
hard prase
),就不能不说一下
Oracle
对
sql
的处理过程。当你发出一条
sql
语句交付
Oracle
,在执行和获取结果前,
Oracle
对此
sql
将进行几个步骤的处理过程:
1、语法检查(
syntax check
)
&nb ......