detailed

oracle-绑定变量-详解（Oracle-boundvariables-

detailed）

oracle-绑定变量-详解(Oracle-boundvariables-detailed)Oracle绑定

变量详解Oracle绑定变量详解

之前整理过一篇有关绑定变量的文章，不太详细，重新补充一下。

Oracle绑定变量

一。绑定变量

绑定变量:SQL语句中的变量，必须用有效值或值的地址替换，以便语句成功执

行。

变量绑定是OLTP系统中一个非常值得关注的技术。良好的变量绑定会使OLTP

系统数据库中的SQL执行速度飞快，内存效率极高;不使用绑定变量可能会使OLTP

数据库不堪重负，资源被SQL解析严重耗尽，系统运行缓慢。

当一个用户与数据库建立连接后，会向数据库发出操作请求，即向数据库送过

去SQL语句。OracleSQL后在接收到这些，会先对这个SQL做一个哈希函数运

算，得到一个哈希值，然后到共享池中寻找是否有和这个哈希值匹配的SQL存在。

如果找到了，Oracle将直接使用已经存在的SQL的执行计划去执行当前的SQL，然

后将结果返回给用户。如果在共享池中没有找到相同哈希值的SQL，Oracle会认为

这是一条新的会进行解析SQL。

Oracle解析的步骤如下:

(1)语法解析

(2)语义解析

(3)生成执行计划，这里分软解析和硬解析。硬解析是非常耗资源的。

(4)SQL的执行

关于SQL的解析，详见博客:

OracleSQL的硬解析和软解析

了解了SQL的执行过程，在来看一些绑定变量，绑定变量的本质就是本来需要

做OracleSQL变成软解析硬解析的，以减少OracleSQL解析上的时间和资源花费

在。

加入有两条SQL:

选择薪酬从用户name='一';;

选择薪酬从用户name='B';;

如果没有用绑定变量，那么这2条SQL会被解析2次，因为他们的谓词部分不

一样如果我们用了绑定变量，如:

从用户名(==x)中选择工资;

这时，之前的2条SQL就变成了一种SQL，Oracle只需要对每一种

SQL做一次硬解析，之后类似的SQL都使用这条SQL产生的执行计划，这样就

可以大大降低数据库花费在SQL解析上的资源开销。这种效果当SQL执行的越多，

就越明显。

简单的说，绑定变量就是拿一个变量来代替谓词常量，让OracleSQL做每次

对用户发来的哈希运算时，运算出的结果都是同样的哈希值，于是将所有的用户发

来的SQL看作是同一个SQL来对象。

二OLAP和OLTP系统中的绑定变量。

OLAP和OLTP系统是有很大差异的他们之间的区别，详细参考博客:

OracleOLAP与OLTP介绍

在OLTP系统中，我们可以使用绑定变量是因为在OLTP中，SQL语句大多是比

较简单或者操作的结果集都很小。当一个表上创建了索引，那么这种极小结果集的

操作使用索引最合适，并且几乎所有的SQL的执行计划的索引都会被选择，因为这

种情况下，索引可能只需要扫描几个数据块就可以定位到数据，而全表扫描将会相

当耗资源。因此，这种情况下，即使每个用户的谓词条件不一样，执行计划也是一

样的，就是都用索引来访问数据，基本不会出现全表扫描的情况。在这种执行计划

几乎唯一的情况下，使用绑定变量来代替谓词常量，是合适的。

在OLAP系统中，SQL的操作就复杂很多，OLAP数据库上大多数时候运行的一

些报表这些SQL，SQL经常会用到聚合查询(如:组)，而且结果集也是非常庞大，在

这种情况下，索引并不是必然的选择，甚至有时候全表扫描的性能会更优于索引，

即使相同的SQL，如果谓词不同，

Theimplementationplanmayvary.

ForOLAPsystemboundvariables,therearethefollowingprinciples:

(1)OLAPsystemthereisnoneedtobindvariables,thatwillonly

bringnegativeeffects,suchascausingSQLtochoothewrong

execution,thispriceissometimesdisastrous;letOracledothehard

analysisforeachSQL,knowexactlythevalueoftheconditionpredicate,

whichiscriticalfortheplanchoice,thereasonforthisyes,inthe

OLAPsystem,SQLhardanalysiscostisnegligible,theresourcesofthe

systemisbasicallyudforbiggerthanSQLqueries,andquery,SQL

's

importanttogetanoptimalexecutionplan.

(2)inOLAPsystems,itiscriticalthatOracleknowexactlywhat

thepredicate'svalueis,anditdirectlydeterminesthechoiceofthe

SQLexecutionplan,sothatthemethodisnotboundbyvariables.

(3)intheOLAPsystemtable,indexanalysisisvital,becauitis

thesourceandbasisofOracletomaketherightexecutionplanforthe

SQLinformation,soitneedstoestablishatofanalysiscanmeetthe

systemrequirementsforimplementationoftheJobobject.

aking

Readthedescriptionoftheofficialwebsitefirst:

Thequeryoptimizerpeeksatthevaluesofur-definedbind

atureenablesthe

optimizertodeterminethelectivityofanyWHEREclauconditionas

ifliteralshavebeenudinsteadofbindvariables.

Toensuretheoptimalchoiceofcursorforagivenbindvalue,

temmonitorsthe

dataaccessperformedbythequeryovertime,dependingonthebind

peekingtakesplace,andifthedatabausa

histogramtocomputelectivityofthepredicatecontainingthebind

variable,thenthedatabamarksthecursorasbind-nsitive.

Wheneverthedatabadeterminesthatacursorproduces

significantlydifferentdataaccesspatternsdependingonthebind

values,Databa

switchestobind-awarecursormatchingtolectthecursorforthis

nd-awarecursormatchinginabled,thedataba

lectsplansbadonthebindvalueandtheoptimizerestimateofits

nd-awarecursormatching,aSQLstatementwithur-

definedbindvariablecanhavemultipleexecutionplans,dependingon

thebindvalues.

WhenbindvariablesappearinaSQLstatement,thedatabaassumes

thatcursorsharingisintendedandthatdifferentinvocationsuthe

erentinvocationsofthecursor

significantlybenefitfromdifferentexecutionplans,thenbind-aware

cursormatchingisrequired.

Bindpeekingdoesnotworkforallclients,butaspecifictof

clients.

From:#PFGRF94588

BindPeekingisanewfeatureintroducedinOracle9i,whoroleis

tolookatthevalueofthecurrentSQLpredicatewhentheSQLstatement

ishardtopar,

thepreviousversionofOracle9i,Oraclemadetheexecutionplanonly

onthebasisofstatistics.

ItshouldbenotedthattheBindPeekingonlytakesplaceduring

hardanalysis,i.e.,whenSQLisfirstexecuted,andthesubquent

eethattheBindpeekingcannot

ultimatelysolvedifferentpredicateexecutionplanledtothelection

ofdifferentproblems,itcanonlymakeSQLthefirstimplementationof

theplanlectionismoreaccurate,andcannothelpOLAPsystemto

solvetheboundvariablesleadstowrongexecutionplanlection

alsoonereasonOLAPshouldnotubindvariables.

Sumup:

ForOLTPsystem,SQLrepeatthesamefrequencyisveryhigh,ifthe

optimizerrepeatedlyparsingSQL,willgreatlyconsumesystemresources,

inaddition,theOLTPsystemurrequestsatofresultsarevery

small,ekingafterthe

firstaccesstoacorrectexecutionplan,allsubquentSQLixecuted

accordingtothixecutionplan,whichgreatlyimprovestheperformance

of

thesystem.

ForOLAPsystems,theSQLexecutionplanandpredicaterelationship

aregreat,cutionplanmay

ameexecutionplanisadopted,theexecution

tion,aOLAPimplementation

oftheSQLsystemdatabaeverydaythenumberisfarlessthanOLTP,

andtherepetitionrateofSQLismuchlowerthantheOLTPsystem,in

thiscondition,thecostofSQLandSQLparsingtakexecutioncost

comparedtothecostofparsingcanbecompletelyignored.

Therefore,forOLAPsystems,nobindvariablesarerequired,andif

er,ifyouua

boundvariable,BindPeekingcanonlyguaranteethatthefirsthard

parSQLcancorrectlylecttheexecutionplan,andifthefollowing

predicatechanges,itislikelythatthewrongexecutionplanwillstill

ult,bindvariablesarenotrecommendedinOLAP

systems.

Collate