最近做了個項目，實現(xiàn)對存在千萬條記錄的庫表進行插入、查詢操作。原以為對數(shù)據(jù)庫的插入、查詢是件很容易的事，可不知當(dāng)數(shù)據(jù)達到百萬甚至千萬條級別的時候，這一切似乎變得相當(dāng)困難。幾經(jīng)折騰，總算完成了任務(wù)。

為盤龍等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及盤龍網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站設(shè)計制作、網(wǎng)站制作、盤龍網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

1、 避免使用Hibernate框架

Hibernate用起來雖然方便，但對于海量數(shù)據(jù)的操作顯得力不從心。

關(guān)于插入：

試過用Hibernate一次性進行5萬條左右數(shù)據(jù)的插入，若ID使用sequence方式生成，Hibernate將分5萬次從數(shù)據(jù)庫取得5萬個sequence，構(gòu)造成相應(yīng)對象后，再分五萬次將數(shù)據(jù)保存到數(shù)據(jù)庫?；宋沂昼姇r間。主要的時間不是花在插入上，而是花在5萬次從數(shù)據(jù)庫取sequence上，弄得我相當(dāng)郁悶。雖然后來把ID生成方式改成increase解決了問題，但還是對那十分鐘的等待心有余悸。

關(guān)于查詢：

Hibernate對數(shù)據(jù)庫查詢的主要思想還是面向?qū)ο蟮?，這將使許多我們不需要查詢的數(shù)據(jù)占用了大量的系統(tǒng)資源（包括數(shù)據(jù)庫資源和本地資源）。由于對Hibernate的偏愛，本著不拋棄、不放棄的作風(fēng)，做了包括配SQL，改進SQL等等的相當(dāng)多的嘗試，可都以失敗告終，不得不忍痛割愛了。

2、 寫查詢語句時，要把查詢的字段一一列出

查詢時不要使用類似select * from x_table的語句，要盡量使用select id,name from x_table，以避免查詢出不需要的數(shù)據(jù)浪費資源。對于海量數(shù)據(jù)而言，一個字段所占用的資源和查詢時間是相當(dāng)可觀的。

3、 減少不必要的查詢條件

當(dāng)我們在做查詢時，常常是前臺提交一個查詢表單到后臺，后臺解析這個表單，而后進行查詢操作。在我們解析表單時，為了方便起見，常常喜歡將一些不需要查詢的條件用永真的條件來代替（如：select count(id) from x_table where name like ‘%’），其實這樣的SQL對資源的浪費是相當(dāng)可怕的。我試過對于同樣的近一千萬條記錄的查詢來說，使用select count(id) from x_table 進行表查詢需要11秒，而使用select count(id) from x_table where name like ‘%’卻花了33秒。

4、 避免在查詢時使用表連接

在做海量數(shù)據(jù)查詢時，應(yīng)盡量避免表連接（特別是左、右連接），萬不得已要進行表連接時，被連接的另一張表數(shù)據(jù)量一定不能太大，若連接的另一張表也是數(shù)萬條的話，那估計可以考慮重新設(shè)計庫表了，因為那需要等待的時間決不是正常用戶所能忍受的。

5、 嵌套查詢時，盡可能地在***次select就把查詢范圍縮到最小

在有多個select嵌套查詢的時候，應(yīng)盡量在最內(nèi)層就把所要查詢的范圍縮到最小，能分頁的先分頁。很多時候，就是這樣簡單地把分頁放到內(nèi)層查詢里，對查詢效率來說能形成質(zhì)的變化。

就是這些了，希望對遇到類似問題的朋友們能有所幫助！

【編輯推薦】

1. Oracle中視圖的創(chuàng)建和處理方法
2. 詳解Oracle幾種性能調(diào)優(yōu)方法
3. 簡述Oracle數(shù)據(jù)倉庫的體系結(jié)構(gòu)

當(dāng)前名稱：Oracle千萬條記錄插入與查詢小結(jié)
網(wǎng)址分享：http://uogjgqi.cn/article/dhsseic.html