ORACLE 处理大量数据应该注意什么？

[絮絮]

实在受不了这样的速度了，今个得说说了，现在有几张级联关系的表，数据很大，有几百万条吧，简单的查询还可以，当用到分页查询的时候，速度慢的要死，大概半分钟，主要是由于，我的查询是在视图中查询的，而且这张视图是复杂的查询，分页的查询的sql语句还要嵌套3次，所以，速度一降再降。另外，在对一张单表（200万条）进行批量更新（更新1万条），速度更是慢，大概用了20分钟，人都等死了，看了几篇小说，一看出错了，还要重新更新，晕……
哈哈，悲剧就这样发生了，想必，这种事情没在你身上发生吧，遇到这样的问题就像踩了狗屎一样幸运，接下来，在网上查了很多如何提高oracle查询和更新效率的方法，一方面，自己分享一下自己的经验，另外，希望您给你宝贵意见或建议，OK！
查询：首先我的查询是从视图中查询的，视图的结构也比较复杂，所以，此视图废弃，选择物化视图，当然，以前没用过，结果太不可思议了，速度提高了很多，本来20s，现在只用0.几秒搞定，呵呵，如获至宝……
更新：百万级的单表数据进行更新（更新1万条），真的委屈CPU了，20分钟才完成此项任务，真想开了它，怎么办呢，想办法。我的批量更新是在事务中做的，带条件的更新某字段的值（Excel读取的），想到每条数据更新时首先要找到这条数据，所有，如果查询时间短了，效率肯定会提高，怎样提高单表查询呢，幸运的我终于想到了索引，加上索引后，继续导入，哈哈，这下了开了花，20分钟缩短到了2分钟，帅气……
当然，oracle定会更快、更强，只是本人水平有限而已，不然，几十万的ORACLE真要打水漂了……
希望各位留在你们的足迹，thanks

[kingkingzhu]

呵呵 帮顶

[絮絮]

[Quote=引用 4 楼 ojuju10 的回复:]

尽量不要用update,update的效率太慢了

更新操作一般是删除索引，楼主建立索引也很快，哈哈
[/Quote]
不是吧，不是所有的更新都会重建索引的吧，我没有更新带索引的列，所以，索引应该不会降低更新的效率的，我也知道，更新的效率很慢，但必须要更新，难道非要我删除后再插入？

[strive_bo]

去建立强制索引 用存储过程 尽量把待查询的数据放到一张虚表中 然后在进行对虚表操作。

还有要尽量少使用delete等语句，要使用turncate或者drop。

建立索引也要根据情况而建立，因为多建立了索引会增加对数据库的负担 使新增等减慢。。。

。。。

[酷恒]

应该是你的分页算法效率的问题，查询语句中，最好用索引字段做关联。

[Dream_1986]

[Diza1986]

csdn是一个理想的交流学习平台
顶一下

[gelyon]

效能优化一直是我们从事应用开发的一大课题，客户总是反应咋出张报表都要花费近1分钟啊？想想也是，客户是上帝，出钱供我们的都他妈是上帝，没法，帮提升效能撒，经验都是一点点积累起来的，我们也从中学到了很多，相信大家回过头来想想，觉得自己还是蛮值得了。

[碧水幽幽泉]

[Quote=引用 11 楼 gelyon 的回复:]
效能优化一直是我们从事应用开发的一大课题，客户总是反应咋出张报表都要花费近1分钟啊？想想也是，客户是上帝，出钱供我们的都他妈是上帝，没法，帮提升效能撒，经验都是一点点积累起来的，我们也从中学到了很多，相信大家回过头来想想，觉得自己还是蛮值得了。
[/Quote]
mark!

[DYFDWX]

[Quote=引用 11 楼 gelyon 的回复:]
效能优化一直是我们从事应用开发的一大课题，客户总是反应咋出张报表都要花费近1分钟啊？想想也是，客户是上帝，出钱供我们的都他妈是上帝，没法，帮提升效能撒，经验都是一点点积累起来的，我们也从中学到了很多，相信大家回过头来想想，觉得自己还是蛮值得了。
[/Quote]

是的，我支持

[da21]

[Quote=引用 2 楼 tianlesoftware 的回复:]
查询慢尽量从SQL上去优化。 数据库只是存放数据的。 它优化的余地很小。
[/Quote]


“数据库只是存放数据的。 它优化的余地很小”这句我不赞同。
数据库的配置、设计是很重要的。SQL的优化是要依据数据库的。

[iqlife]

感觉一般表设计得合理的话，几百万的记录应该还不至于太慢，
肯定业务上也是需要改善的，慢的话，适当增加冗余，减少表关联

[registerluo]

新建索引可以提高查询的速度,但是批量更新时,和批量插入时,数据库的性能会很慢,
这就是索引的缺点

[gelyon]

楼主是来向我们传授经验的，学习了！

[crazylaa]

分区要钱买，唉。

[epsilon-delta]

说说我处理大数据量应用的设计思路

1. 是否需要那么多数据量、是否需要这种低效的功能
记得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. 并行处理
大数据量的处理，并行也是一个重要思路，但并行的一个关键就是要有好的并行机制，尽可能保证各个并行粒度间不再有交互和争用，这是确保并行的线性扩展能力的一个重要因素
比如批量处理时，如果并行粒度正好就是分区的粒度那就很好，因为各个分区的资源是互相独立的（当然这个是在底层的表空间是独立的基础上），但是如果在这个表上还有不分区的索引，而且索引字段又是批量处理中会被修改的数据，那这个索引就又成为了争用的地方，从并行批量角度看这个索引设计的可能就不是很合适，但真正结果还是由实际背景决定。

[酸饼]

先mark一下，国庆回来再写写这方面的总结

[daodao_道道]

我以前做数据仓库的时候，一般的sql都是上千万的操作，oracle的大数据处理能力还是很强的，

[碧水幽幽泉]

[Quote=引用 21 楼 huangchao_sky 的回复:]
我以前做数据仓库的时候，一般的sql都是上千万的操作，oracle的大数据处理能力还是很强的，
[/Quote]
mark!

[palm_civet]

1. 分区表
2.
想到每条数据更新时首先要找到这条数据，所有，如果查询时间短了，效率肯定会提高

你是每条数据都注意查询的么，建议用临时表，只用一句sql完成校验

[scorpions_z]

学习中！！