在JAVA中的SQL 語句的編寫方面，沒有使用ORACLE 綁定變量，很大程度上降低了數(shù)據(jù)庫的性能，表現(xiàn)在兩個(gè)方面：

1、SQL語句硬分析(Hard Parse)太多，嚴(yán)重消耗CPU資源，延長了SQL語句總的執(zhí)行時(shí)間

SQL語句的執(zhí)行過程分幾個(gè)步驟：語法檢查、分析、執(zhí)行、返回結(jié)果。其中分析又分為硬分析(Hard Parse)和軟分析(Soft Parse)。

一條SQL語句通過語法檢查后，Oracle 會先去shared pool 中找是否有相同的sql，如果找著了，就叫軟分析，然后執(zhí)行SQL語句。

硬分析主要是檢查該sql所涉及到的所有對象是否有效以及權(quán)限等關(guān)系，然后根據(jù)RBO或CBO模式生成執(zhí)行計(jì)劃，然后才執(zhí)行SQL語句。

可以看出，硬分析比軟分析多了很多動作，而這里面的關(guān)鍵是“在shared pool 中是否有相同的sql”，而這就取決于是否使用綁定變量。

2、共享池中SQL語句數(shù)量太多，重用性極低，加速了SQL語句的老化，導(dǎo)致共享池碎片過多。

共享池中不同的SQL語句數(shù)量巨大，根據(jù)LRU原則，一些語句逐漸老化，最終被清理出共享池；這樣就導(dǎo)致shared_pool_size 里面命中率

下降，共享池碎片增多，可用內(nèi)存空間不足。而為了維護(hù)共享池內(nèi)部結(jié)構(gòu)，需要使用latch，一種內(nèi)部生命周期很短的lock，這將使用大量的cpu 資源，使得性能急劇下降。

不使用綁定變量違背了oracle 的shared pool 的設(shè)計(jì)的原則，違背了這個(gè)設(shè)計(jì)用來共享的思想。編寫java 程序時(shí)，我們習(xí)慣都是定義JAVA 的程序變量，放入SQL 語句中，如

String v_id = 'xxxxx';

String v_sql = 'select name from table_a where id = ' + v_id ;

以上代碼，看起來是使用了變量v_id ，但這卻是java 的程序變量，而不是oracle 的綁定變量，語句傳遞到數(shù)據(jù)庫后，此java 的程序變量已經(jīng)被替換成具體的常量值，變成：

select * from table_a where name = 'xxxxx' ;

假定這個(gè)語句第一次執(zhí)行，會進(jìn)行硬分析。后來，同一段java 代碼中v_id 值發(fā)現(xiàn)變化(v_id = 'yyyyyy')，數(shù)據(jù)庫又接收到這樣的語句：

select * from table_a where name = 'yyyyyy' ;

ORACLE 并不認(rèn)為以上兩條語句是相同的語句，因此對第二條語句會又做一次硬分析。這兩條語句的執(zhí)行計(jì)劃可是一樣的！

其實(shí)，只需將以上java 代碼改成以下這樣，就使用了oracle 的綁定變量：

String v_id = 'xxxxx';

String v_sql = 'select name from table_a where id = ? '; //嵌入綁定變量

stmt = con.prepareStatement( v_sql );

stmt.setString(

總結(jié)

以上是生活随笔為你收集整理的java绑定变量怎么加_在JAVA 源程序中编写SQL语句时使用ORACLE 绑定变量的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。