Oracle千万条记录插入与查询小结
时间:2016-12-13 12:31 来源:linux.it.net.cn 作者:IT
最 近做了个项目，实现对存在千万条记录的库表进行插入、查询操作。原以为对数据库的插入、查询是件很容易的事，可不知当数据达到百万甚至千万条级别的时候， 这一切似乎变得相当困难。几经折腾，总算完成了任务。在此做些简单的小结，不足之处，还望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，以避免查询出不需要的数据浪费资源。对于海量数据而言，一个字段所占用的资源和查询时间是相当可观的。 [/size]
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，怎样造Java对象。有句话说得好：尽可能的少造对象。别说千万级，就是上万级都不要考虑造对象了。因为几个请求一并发，喀嚓，系统肯定完蛋。
2，合理摆正系统设计的位置。大量数据操作，和少量数据操作一定是分开的。大量的数据操作，肯定不是ORM框架搞定的。绝对不能ORM，因为1，要少造对象；2，数据库资源合理利用。就像博主的例子：id分配就是一个好例子。
3，合理利用数据库的分区、索引技术。
4，有的时候可以考虑临时表之类的，尤其是大数据量。
5，有人说非常大的数据量，一定要用存储过程。我存储过程不好，所以还是使用jdbc，哈哈效果非常好，所以除了上面几点注意外，还要注意：
1，控制好内存，让数据流起来，而不是全部读到内存再处理，而是边读取边处理；
2，合理利用内存，有的数据要缓存；
3，偶承认，这里技术含量还是有的，反正不简单。不好言传。
(责任编辑：IT)
| 最 近做了个项目，实现对存在千万条记录的库表进行插入、查询操作。原以为对数据库的插入、查询是件很容易的事，可不知当数据达到百万甚至千万条级别的时候， 这一切似乎变得相当困难。几经折腾，总算完成了任务。在此做些简单的小结，不足之处，还望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，以避免查询出不需要的数据浪费资源。对于海量数据而言，一个字段所占用的资源和查询时间是相当可观的。 [/size] 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，怎样造Java对象。有句话说得好：尽可能的少造对象。别说千万级，就是上万级都不要考虑造对象了。因为几个请求一并发，喀嚓，系统肯定完蛋。 2，合理摆正系统设计的位置。大量数据操作，和少量数据操作一定是分开的。大量的数据操作，肯定不是ORM框架搞定的。绝对不能ORM，因为1，要少造对象；2，数据库资源合理利用。就像博主的例子：id分配就是一个好例子。 3，合理利用数据库的分区、索引技术。 4，有的时候可以考虑临时表之类的，尤其是大数据量。 5，有人说非常大的数据量，一定要用存储过程。我存储过程不好，所以还是使用jdbc，哈哈效果非常好，所以除了上面几点注意外，还要注意： 1，控制好内存，让数据流起来，而不是全部读到内存再处理，而是边读取边处理； 2，合理利用内存，有的数据要缓存； 3，偶承认，这里技术含量还是有的，反正不简单。不好言传。 (责任编辑：IT) |