最近做了个项目，完成对存在千万条记载的库表进行刺进、查询操作。原以为对数据库的刺进、查询是件很简略的事，可不知当数据到达百万乃至千万条等级的时分，这一切好像变得适当困难。几经折腾，总算完成了使命。

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. Oracle中视图的创建和处理办法
2. 详解Oracle几种功能调优办法
3. 简述Oracle数据仓库的体系结构