浅谈Oracle绑定变量

绑定变量在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文件关键内容：