我們開發(fā)的是一套大型門戶系統(tǒng)，因?yàn)槭荌nternet訪問的，所以，Statement會出現(xiàn)安全問題，這個(gè)在

http://blog.csdn.net/hongbo781202/archive/2005/09/19/485092.aspx里面已經(jīng)討論過了，然后我抄一段ORACLE電子雜志的話給大家看看：“除了緩沖的問題之外，至少還有一個(gè)更好的原因使我們在企業(yè)應(yīng)用程序中更喜歡使用 PreparedStatement對象,那就是安全性。傳遞給PreparedStatement對象的參數(shù)可以被強(qiáng)制進(jìn)行類型轉(zhuǎn)換，使開發(fā)人員可以確保在插入或查詢數(shù)據(jù)時(shí)與底層的數(shù)據(jù)庫格式匹配。
當(dāng)處理公共Web站點(diǎn)上的用戶傳來的數(shù)據(jù)的時(shí)候，安全性的問題就變得極為重要。傳遞給 PreparedStatement的字符串參數(shù)會自動(dòng)被驅(qū)動(dòng)器忽略。最簡單的情況下，這就意味著當(dāng)你的程序試著將字符串“DAngelo”插入到 VARCHAR2中時(shí)，該語句將不會識別第一個(gè)“，”，從而導(dǎo)致悲慘的失敗。幾乎很少有必要?jiǎng)?chuàng)建你自己的字符串忽略代碼。
在Web環(huán)境中，有惡意的用戶會利用那些設(shè)計(jì)不完善的、不能正確處理字符串的應(yīng)用程序。特別是在公共Web站點(diǎn)上,在沒有首先通過PreparedStatement對象處理的情況下，所有的用戶輸入都不應(yīng)該傳遞給SQL語句。此外，在用戶有機(jī)會修改SQL語句的地方，如HTML的隱藏區(qū)域或一個(gè)查詢字符串上，SQL語句都不應(yīng)該被顯示出來。”。這段話和我們?nèi)豪锩娴挠懻撘荒Ｒ粯印?BR>
關(guān)于性能問題，再給大家看段話：“通常認(rèn)為PreparedStatement 對象比Statement對象更有效,特別是如果帶有不同參數(shù)的同一SQL語句被多次執(zhí)行的時(shí)候。PreparedStatement對象允許數(shù)據(jù)庫預(yù)編譯SQL語句，這樣在隨后的運(yùn)行中可以節(jié)省時(shí)間并增加代碼的可讀性。
然而，在Oracle環(huán)境中，開發(fā)人員實(shí)際上有更大的靈活性。當(dāng)使用 Statement或PreparedStatement對象時(shí)，Oracle數(shù)據(jù)庫會緩存SQL語句以便以后使用。在一些情況下,由于驅(qū)動(dòng)器自身需要額外的處理和在Java應(yīng)用程序和Oracle服務(wù)器間增加的網(wǎng)絡(luò)活動(dòng)，執(zhí)行PreparedStatement對象實(shí)際上會花更長的時(shí)間。”

實(shí)際上，我的測試結(jié)果是：在同一SQL執(zhí)行5次的情況下，PrepareStatement比Statement要慢3%.

我們再看看http://www.oreilly.com/catalog/jorajdbc/chapter/ch19.html
里面有詳細(xì)的圖表說明為什么Statement比PreparedStatement快。結(jié)論是：一個(gè)prepared statement要執(zhí)行65次以上才能趕上一個(gè)普通statement的執(zhí)行效率。

另外一個(gè)問題就是Index的使用，基本的原則就是： 如果是多列Index，一般應(yīng)該保證這幾個(gè)列都在查詢條件中。而且對于單列Index，只有滿足查詢出來的結(jié)果命中率在20%以下，使用索引會才會加快速度！ 否則可能會越Index越慢哦!

根據(jù)經(jīng)驗(yàn)看，上面的結(jié)論對Oracle,Sybase,Mysql,Informix都成立，好可怕啊，不知道我前兩年的程序怎么做的，原來我前兩年都是在謊言的邊緣度過！