一個(gè)好的建議是，直接使用Oracle的統(tǒng)計(jì)表。我們可以清除SQL語句的緩沖池，在大連讀屏軟件開發(fā)執(zhí)行過程中，觀察緩沖池中SQL語句的執(zhí)行狀況，例如，執(zhí)行次數(shù)、平均執(zhí)行時(shí)間等。我們選取了那些Top SQL，對(duì)它們的執(zhí)行計(jì)劃進(jìn)行了分析。
通過參閱相關(guān)資料和多次嘗試，我們得到了一些經(jīng)驗(yàn)知識(shí)：
提升大連讀屏軟件開發(fā)SQL語句的執(zhí)行效率本質(zhì)上就是降低磁盤的訪問次數(shù)，通常來說，可以通過建立索引和避免對(duì)大數(shù)據(jù)量的表進(jìn)行全表掃描來實(shí)現(xiàn)；
索引稠密度并不能完全說明建立索引的合理性，還需要考慮數(shù)據(jù)分布，因此，索引應(yīng)該盡量建在取值比較均勻的字段上。
這些經(jīng)驗(yàn)知識(shí)幫助我們明確了SQL語句的優(yōu)化方向，同時(shí)也取得了很好的效果。我們甚至利用Oracle的特性來建立或屏蔽動(dòng)態(tài)索引以及干涉SQL語句的執(zhí)行路徑?？傊?，目標(biāo)只有一個(gè)——降低磁盤的訪問次數(shù)。
在對(duì)緩沖池的觀察中，我們還發(fā)現(xiàn)很多相似的大連讀屏軟件開發(fā)語句大量出現(xiàn)，這顯然是沒有使用綁定變量的緣故。在單用戶下，這種做法導(dǎo)致的性能問題可能還不明顯，但是在多用戶并發(fā)的情況下（換句話說，在數(shù)據(jù)庫訪問極其頻繁的情況下），會(huì)產(chǎn)生性能問題。這是因?yàn)椋彌_池是有一定容量限制的，當(dāng)不斷有新的SQL語句進(jìn)入時(shí)，原先的SQL語句會(huì)被移除，這導(dǎo)致了SQL語句的硬解析。硬解析會(huì)使優(yōu)化器重新創(chuàng)建解析樹和生成執(zhí)行計(jì)劃，而這兩個(gè)動(dòng)作都是代價(jià)昂貴的，會(huì)影響SQL語句的執(zhí)行性能。
致遠(yuǎn)服軟認(rèn)為：http://www.soft8.com.cn/至此，對(duì)于SQL語句執(zhí)行性能的問題，我們已經(jīng)有了比較明確的解決方案。事實(shí)上，在以上提到的性能問題中，哪一點(diǎn)是軟件設(shè)計(jì)和實(shí)現(xiàn)中無法避免的呢？沒有。
我們把視線轉(zhuǎn)向單個(gè)事務(wù)中的數(shù)據(jù)庫訪問次數(shù)。令人震驚的是，在一個(gè)事務(wù)中，竟然有幾千次的數(shù)據(jù)庫訪問。每一次數(shù)據(jù)庫訪問，都需要客戶端和服務(wù)器端的交互。這種交互會(huì)在網(wǎng)絡(luò)上傳遞“相當(dāng)可觀”的字節(jié)數(shù)，更不要說CPU和內(nèi)存上的消耗。
我們對(duì)這個(gè)現(xiàn)象進(jìn)行了分析，很快發(fā)現(xiàn)以下的問題。首先，系統(tǒng)中存在JDBC和Hibernate混用的情況。這導(dǎo)致了Hibernate大量的flush動(dòng)作，flush會(huì)產(chǎn)生數(shù)據(jù)庫的操作。這種做法讓人厭惡。
這是軟件設(shè)計(jì)和實(shí)現(xiàn)中無法避免的嗎？不。其次，很多方法使用ID作為參數(shù)，每一次調(diào)用都要通過ID來構(gòu)建數(shù)據(jù)對(duì)象，這導(dǎo)致了大量的數(shù)據(jù)庫訪問。這是軟件設(shè)計(jì)和實(shí)現(xiàn)中無法避免的嗎？不。
最后，在循環(huán)中通過JDBC來訪問數(shù)據(jù)庫，如果循環(huán)次數(shù)很多，數(shù)據(jù)庫訪問次數(shù)會(huì)讓人發(fā)瘋。
這是安全漏洞軟件測試和實(shí)現(xiàn)中無法避免的嗎？
我們嘗試使用減少flush次數(shù)、傳遞對(duì)象、循環(huán)體外準(zhǔn)備數(shù)據(jù)等方式來解決上面的問題。盡管取得了一定的效果，但感覺很差。如此大規(guī)模的程序，其結(jié)構(gòu)仿佛來自本能，而不是來自良好的規(guī)劃。
