今天一天幾乎都是在與數(shù)據(jù)庫打交道，碰到過去從未想過也不曾碰到過的問題，也讓我對數(shù)據(jù)庫有了一些新的認(rèn)識，新的感受，主要是兩個(gè)方面，一個(gè)是ORDER BY，一個(gè)是Batch。
情景一：有兩張表，一張有100萬條記錄，另一張有300萬條記錄。
最初的SQL是連接兩張表，并對其中一個(gè)表的非索引字段排序，并取出幾千條的數(shù)據(jù)，花費(fèi)了很長的時(shí)間，最終分析得出，大部分時(shí)間花在排序上。后來去掉了ORDER BY并使用客戶端的Utils方法對已經(jīng)取出的數(shù)據(jù)進(jìn)行排序，查詢速度大大優(yōu)化。
情景二：對取出的結(jié)果進(jìn)行一定的處理，并更新其中一張表。
最初的辦法是處理一個(gè)更新一個(gè)，效率很低，最后和老員工交流經(jīng)驗(yàn)得到真?zhèn)鳎谑菦Q定使用Batch來批量更新數(shù)據(jù)庫，效率極大的提高，有一個(gè)數(shù)量級，但是因?yàn)槲冶镜乜蛻舳藳]有裝DB2的升級補(bǔ)丁，無法在客戶端更新，在服務(wù)器上更新成功。
總結(jié)，數(shù)據(jù)庫的訪問效率應(yīng)該是這類系統(tǒng)最主要的瓶頸，多花點(diǎn)時(shí)間放在查詢語句和查詢策略上，有時(shí)候效率提高會很大。
posted on 2005-11-28 17:24
steady 閱讀(469)
評論(0) 編輯 收藏 所屬分類:
技術(shù)隨筆