Oracle千萬條記錄插入與查詢小結
關鍵字: oracle 海量 查詢 效率 優化
最 近做了個項目,實現對存在千萬條記錄的庫表進行插入、查詢操作。原以為對數據庫的插入、查詢是件很容易的事,可不知當數據達到百萬甚至千萬條級別的時候, 這一切似乎變得相當困難。幾經折騰,總算完成了任務。在此做些簡單的小結,不足之處,還望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嵌套查詢的時候,應盡量在最內層就把所要查詢的范圍縮到最小,能分頁的先分頁。很多時候,就是這樣簡單地把分頁放到內層查詢里,對查詢效率來說能形成質的變化。
就是這些了,希望對遇到類似問題的朋友們能有所幫助!
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嵌套查詢的時候,應盡量在最內層就把所要查詢的范圍縮到最小,能分頁的先分頁。很多時候,就是這樣簡單地把分頁放到內層查詢里,對查詢效率來說能形成質的變化。
就是這些了,希望對遇到類似問題的朋友們能有所幫助!
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
