当前位置:Gxlcms > mysql > 浅谈Oracle绑定变量

浅谈Oracle绑定变量

时间:2021-07-01 10:21:17 帮助过:44人阅读

绑定变量在OLTP环境下,被广泛的使用;这源于OLTP的特点和sql语句的执行过程,OLTP典型的事务短,类似的sql语句执行率高,并发大;oracle在执行sql语句前会对sql

绑定变量在OLTP环境下,被广泛的使用;这源于OLTP的特点和sql语句的执行过程,OLTP典型的事务短,类似的sql语句执行率高,并发大;oracle在执行sql语句前会对sql语句进行hash运算,将得到的hash值和share pool中的library cache中对比,网站空间,如果未命中,则这条sql语句需要执行硬解析,如果命中,则只需要进行软解析;硬解析的执行过程是先进行语义,语法分析,然后生成执行计划,最后执行sql语句,在OLTP系统中使用绑定变量可以很好的解决这个问题!

一:oltp环境下,使用绑定变量和不使用绑定变量对比
1:创建测试数据

2:不使用绑定变量情况下,进行sql trace分析,执行1万次,需要硬解析10003次,其中包含递归解析,解析时间为19.37s,cpu消耗为17.62

3:使用绑定变量情况下,进行sql trace分析,香港虚拟主机,执行1万次,只需要硬解析5次,香港空间,其中包含递归解析,解析时间和cpu时间基本忽略不计

二:使用绑定变量有如此好的效果,那么这是不是百利无一害的技术手段呢?下面在OLAP环境下测试
1:创建测试数据,olap环境下分区的技术非常普遍,且数据量非常大

2:查询object_id落在1-5999之间的数据,查看执行计划,这里选择了全表扫描为最优的执行计划

3:查询object_id落在1000-15000之间的数据,查看执行计划,这里选择了索引访问扫描为最优的执行计划


结论:由此可见,使用绑定变量应该尽量保证使用绑定变量的sql语句执行计划应当相同,否则将造成问题,因而绑定变量不适用于OLAP环境中!

三:在前面的测试中,1-5999之间的查询,为什么不选择分区范围扫描?1000-5000之间的查询,为什么不选择全表扫描,使用索引,不会产生无谓的2次I/O吗?要了解这些,就要开启数据库的10053时间,分析cbo如何选择执行计划?

1:分析1-5999之间查询的10053事件

trace文件关键内容:

***************************************
Column Usage Monitoring is ON: tracking level = 1
***************************************
****************
QUERY BLOCK TEXT
****************
select object_id,count(*) from t2 where object_id between 1 and 5999 group by object_id
*********************
QUERY BLOCK SIGNATURE
*********************
qb name was generated
signature (optimizer): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=0 objn=54910 hint_alias="T2"@"SEL$1"
*****************************
SYSTEM STATISTICS INFORMATION
*****************************
Using NOWORKLOAD Stats
CPUSPEED: 587 millions instruction/sec
IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
IOSEEKTIM: 10 milliseconds (default is 10)
***************************************
BASE STATISTICAL INFORMATION
***********************
Table Stats::
Table: T2 Alias: T2 (Using composite stats)
(making adjustments for partition skews)
ORIGINAL VALUES:: #Rows: 15078669 #Blks: 71051 AvgRowLen: 28.00
PARTITIONS::
PRUNED: 2
ANALYZED: 2 UNANALYZED: 0
#Rows: 15078669 #Blks: 10756 AvgRowLen: 28.00
Index Stats::
Index: I_T_ID Col#: 1
USING COMPOSITE STATS
LVLS: 2 #LB: 33742 #DK: 50440 LB/K: 1.00 DB/K: 303.00 CLUF: 15299802.00
Column (#1): OBJECT_ID(NUMBER)
AvgLen: 5.00 NDV: 50440 Nulls: 0 Density: 1.9826e-05 Min: 33 Max: 54914
***************************************
SINGLE TABLE ACCESS PATH
Table: T2 Alias: T2
Card: Original: 15078669 Rounded: 1639470 Computed: 1639469.86 Non Adjusted: 1639469.86
Access Path: TableScan
Cost: 2432.43 Resp: 2432.43 Degree: 0
Cost_io: 2355.00 Cost_cpu: 545542277
Resp_io: 2355.00 Resp_cpu: 545542277
Access Path: index (index (FFS))
Index: I_T_ID
resc_io: 7383.00 resc_cpu: 2924443977
ix_sel: 0.0000e+00 ix_sel_with_filters: 1
Access Path: index (FFS)
Cost: 7798.09 Resp: 7798.09 Degree: 1
Cost_io: 7383.00 Cost_cpu: 2924443977
Resp_io: 7383.00 Resp_cpu: 2924443977
Access Path: index (IndexOnly)
Index: I_T_ID
resc_io: 3671.00 resc_cpu: 358846806
ix_sel: 0.10873 ix_sel_with_filters: 0.10873
Cost: 3721.93 Resp: 3721.93 Degree: 1
Best:: AccessPath: TableScan
Cost: 2432.43 Degree: 1 Resp: 2432.43 Card: 1639469.86 Bytes: 0
Grouping column cardinality [ OBJECT_ID] 5484

2:分析1000-5000之间查询的10053事件

trace文件关键内容:

人气教程排行