浅谈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文件关键内容：