注释:
很少有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优化了解业务多重要。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/28602568/viewspace-1685600/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/28602568/viewspace-1685600/