注释：

很少有dba全知晓整个项目的所有业务，不过sql优化不懂sql 具体业务可能就成了问题；

我们来看看如下情况从业务上优化哈~

(报表)下载功能：

一般业务的下载功能，再避免影响内存溢出、都可能会考虑select .. where rownum<200，每200条一次追加到excel，多次调用sql 实现将全部数据写到excel；

遐想：

当（select ... 表比较多 where rownum<200 ，执行计划都是全扫，且筛选后量较大）情况出现时，如上的多次调用方式就存在很严重的瓶颈；

如上所说的情况，如果是您的话，您会怎么解决捏~

********************************************************************************************************************************************

分析：

如上情况的sql 单独去优化很艰难，所以了解下业务，最终目的是需要将select ... 多表条件..哒哒哒..过滤后所有数据导入到excel表；

瓶颈： 当量较大时，考虑到应用内存溢出问题，所以需要多次调用(较慢的大sql = 120s) ,以每小量数据一步步导入到最终excel中；

方案： 由于最终是全量，所有可以将多次调用的大sql 改为一次调用读写到数据库中的临时表；再一次以200数据取临时表数据；

语句： create table t as select ... 多表条件..哒哒哒..过滤后所有数据；

select * from t where rownum<200；多次调用

总结： 由于知道业务上是需要sql数据最终全量，所以巧用临时表属性，将多次调用较慢的大sql改为一次调用；

且单次执行较慢sql =120s = create 临时表时间，避免应用内存溢出的多次调用临时表时间就及其短暂了..
所以... SQL优化了解业务多重要。

【源于本人笔记】若有书写错误，表达错误，请指正...

此条目发表在 SQL、SQL优化篇分类目录。将固定连接加入收藏夹。

ITPub博客

Oracle SQL优化了解业务多重要