Oracle千萬條記錄插入與查詢小結

來源:互聯網
上載者:User

最近做了個項目,實現對存在千萬條記錄的庫表進行插入、查詢操作。原以為對資料庫的插入、查詢是件很容易的事,可不知當資料達到百萬甚至千萬條層級的時候,這一切似乎變得相當困難。幾經折騰,總算完成了任務。在此做些簡單的小結,不足之處,還望javaeye的高手們幫忙補充補充!

1、 避免使用Hibernate架構
  Hibernate用起來雖然方便,但對于海量資料的操作顯得力不從心。
  關於插入:
  試過用Hibernate一次性進行5萬條左右資料的插入,若ID使用sequence方式產生,Hibernate將分5萬次從資料庫取得5萬個sequence,構造成相應對象後,再分五萬次將資料儲存到資料庫。花了我十分鐘時間。主要的時間不是花在插入上,而是花在5萬次從資料庫取sequence上,弄得我相當鬱悶。雖然後來把ID產生方式改成increase解決了問題,但還是對那十分鐘的等待心有餘悸。

  關於查詢:
  Hibernate對資料庫查詢的主要思想還是物件導向的,這將使許多我們不需要查詢的資料佔用了大量的系統資源(包括資料庫資源和本地資源)。由於對Hibernate的偏愛,本著不拋棄、不放棄的作風,做了包括配SQL,改進SQL等等的相當多的嘗試,可都以失敗告終,不得不忍痛割愛了。

2、 寫查詢語句時,要把查詢的欄位一一列出
  查詢時不要使用類似select * from x_table的語句,要盡量使用select id,name from
x_table,以避免查詢出不需要的資料浪費資源。對于海量資料而言,一個欄位所佔用的資源和查詢時間是相當可觀的。

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

4、 避免在查詢時使用表串連
  在做海量資料查詢時,應盡量避免表串連(特別是左、右串連),萬不得已要進行表串連時,被串連的另一張表資料量一定不能太大,若串連的另一張表也是數萬條的話,那估計可以考慮重新設計庫表了,因為那需要等待的時間決不是正常使用者所能忍受的。

5、 巢狀查詢時,儘可能地在第一次select就把查詢範圍縮到最小
  在有多個select巢狀查詢的時候,應盡量在最內層就把所要查詢的範圍縮到最小,能分頁的先分頁。很多時候,就是這樣簡單地把分頁放到內層查詢裡,對查詢效率來說能形成質的變化。

  就是這些了,希望對遇到類似問題的朋友們能有所協助!
a

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.