实在受不了这样的速度了，今个得说说了，现在有几张级联关系的表，数据很大，有几百万条吧，简单的查询还可以，当用到分页查询的时候，速度慢的要死，大概半分钟，主要是由于，我的查询是在视图中查询的，而且这张视图是复杂的查询，分页的查询的sql语句还要嵌套3次，所以，速度一降再降。另外，在对一张单表（200万条）进行批量更新（更新1万条），速度更是慢，大概用了20分钟，人都等死了，看了几篇小说，一看出错了，还要重新更新，晕……
哈哈，悲剧就这样发生了，想必，这种事情没在你身上发生吧，遇到这样的问题就像踩了狗屎一样幸运，接下来，在网上查了很多如何提高oracle查询和更新效率的方法，一方面，自己分享一下自己的经验，另外，希望您给你宝贵意见或建议，OK！
查询：首先我的查询是从视图中查询的，视图的结构也比较复杂，所以，此视图废弃，选择物化视图，当然，以前没用过，结果太不可思议了，速度提高了很多，本来20s，现在只用0.几秒搞定，呵呵，如获至宝……
更新：百万级的单表数据进行更新（更新1万条），真的委屈CPU了，20分钟才完成此项任务，真想开了它，怎么办呢，想办法。我的批量更新是在事务中做的，带条件的更新某字段的值（Excel读取的），想到每条数据更新时首先要找到这条数据，所有，如果查询时间短了，效率肯定会提高，怎样提高单表查询呢，幸运的我终于想到了索引，加上索引后，继续导入，哈哈，这下了开了花，20分钟缩短到了2分钟，帅气……
当然，oracle定会更快、更强，只是本人水平有限而已，不然，几十万的ORACLE真要打水漂了……
希望各位留在你们的足迹，thanks
哈哈，悲剧就这样发生了，想必，这种事情没在你身上发生吧，遇到这样的问题就像踩了狗屎一样幸运，接下来，在网上查了很多如何提高oracle查询和更新效率的方法，一方面，自己分享一下自己的经验，另外，希望您给你宝贵意见或建议，OK！
查询：首先我的查询是从视图中查询的，视图的结构也比较复杂，所以，此视图废弃，选择物化视图，当然，以前没用过，结果太不可思议了，速度提高了很多，本来20s，现在只用0.几秒搞定，呵呵，如获至宝……
更新：百万级的单表数据进行更新（更新1万条），真的委屈CPU了，20分钟才完成此项任务，真想开了它，怎么办呢，想办法。我的批量更新是在事务中做的，带条件的更新某字段的值（Excel读取的），想到每条数据更新时首先要找到这条数据，所有，如果查询时间短了，效率肯定会提高，怎样提高单表查询呢，幸运的我终于想到了索引，加上索引后，继续导入，哈哈，这下了开了花，20分钟缩短到了2分钟，帅气……
当然，oracle定会更快、更强，只是本人水平有限而已，不然，几十万的ORACLE真要打水漂了……
希望各位留在你们的足迹，thanks
顶一下
数据库的配置、设计是很重要的。SQL的优化是要依据数据库的。
记得Tom Kyte说过类似于“不做一件事情是最高效的”，所以如果从设计角度看，首先要现在这种做法是否是有问题的，从业务角度看所有数据都是有用的，但这和高效的应用是存在冲突的，所以在两难境地下，需要考虑哪些数据是业务最为需要的，也是最频繁使用的，对于这部分重点关注，对于次要的数据这考虑其他方式处理。对于业务功能也是这样考虑，说到底就是需要从业务真正关心的重点出发，而不要被表面的功能形式所左右了比如说以前一个项目需要存储7年的数据，一个月的主表就有7千万条记录，7年也就是至少近5亿的数据量，而分析了实际业务场景后，通常只有近3个月的数据需要真正频繁使用，所以初步思路分为两大类查询功能，对于近3个月的数据按一种方式处理，另外的数据则相对简化处理。2. 充分利用分区机制设计
分区的中心思想就是分而治之，把大数据量按一定规则分成几个小数据集，每次只从需要的小数据集去筛选数据，这样可以有效减少资源的消耗，尤其是I/O。
分区类型我个人认为主要分为两类{RANGE,LIST}算一类，{HASH}算一类，前者可以由应用控制数据归属哪个分区，所以是应用角度有较好的数据分区方案的不错选择，后者是oracle自己控制的，但是有一点好处，就是当作为hash分区的分区字段是一个值域很广的字段，而且数据分布较为随机，那hash分区可以基本确保每个分区的数据量在同一个数量级上，这从均衡分布各个分区的查询等操作开销很有益处。
此外分区不仅限于对于数据分区，表上的索引也推荐使用分区（注意只是推荐，不是绝对的，对于那些用不到分区特性的功能，不分区的索引有时比分区的索引还好点），这样在查询条件中如果有分区字段，那oracle一样是会只从需要的索引分区上查询索引，而不是查询这个表的索引。
对于表关联，分区也有它的好处，具体可以参考partition-wise join。3. 对于索引的建立
这个真的是相当依赖于应用背景，通常对于使用最为频繁的查询，是要考虑使用索引优化效率的，但要说一个大范围适用的原则，真的比较难说，总体来讲就是从平衡角度考虑，提出设计思路，压力测试验证。一般我将索引作为一个最后的方案去考虑，处理索引问题，我通常都是很谨慎的，因为索引对于dml的影响是巨大的。
还有一点就是索引只对于从大量数据中获取少量数据，比如<10%，这种场景比较合适，对于从大量数据获取大量数据的情况下，还不如使用全表扫描更为划算。4. 对于数据修改
也就是dml的效率，dml实际也是先查询到要修改的数据(或者是用来修改其他表的源数据)，再修改数据（除了最简单的insert value这种），所以也就分为两类效率，查询的效率和修改的效率，查询的效率主要就是前面说的那几套，修改的效率，关键我认为就是减少redo log的生成。
比如insert是redo log最少的语句，所以通常对于一张表的大部分数据都要被修改的情况，可以考虑直接使用insert select的方式把修改后的结果插入到新表中，之后再把新表改名为旧表，这比update效率要高出很多。
使用truncate替代delete全表，一个很重要的原因也是truncate没有redo log的生成。5. 并行处理
大数据量的处理，并行也是一个重要思路，但并行的一个关键就是要有好的并行机制，尽可能保证各个并行粒度间不再有交互和争用，这是确保并行的线性扩展能力的一个重要因素
比如批量处理时，如果并行粒度正好就是分区的粒度那就很好，因为各个分区的资源是互相独立的（当然这个是在底层的表空间是独立的基础上），但是如果在这个表上还有不分区的索引，而且索引字段又是批量处理中会被修改的数据，那这个索引就又成为了争用的地方，从并行批量角度看这个索引设计的可能就不是很合适，但真正结果还是由实际背景决定。
2.
想到每条数据更新时首先要找到这条数据，所有，如果查询时间短了，效率肯定会提高你是每条数据都注意查询的么，建议用临时表，只用一句sql完成校验