一次 关于临时表优化表

 现在手头的系统，已经优化了 近4 个月了。其中效果还是很显著的。 如果一个系统中 SQL   70， 80 ， 90， 100， 200， 300 分钟的SQL  一天有  4 ，50 个 现在 搞得 没有超过10 分钟 的，   系统性能 能不提升不？？？

 

 之前和项目经理 吹牛， 说 怎么系统中 有很多临时表？？ 这个性能 无法保证的， 主要保证其执行计划。      项目经理 ：“ 我们系统中用到的临时表 为了就是提示性能”  

哥：“  我说的临时表主要是 指的是 建立在临时表空间中，  比如 一 commit   数据就删除的那种 ， 不是业务上面的临时表， 比如  这个 TMP_XXXX，  这些表只是当临时表用 ” 

 那天果然遇到  临时表问题了。     项目经理：“  这个流程 怎么跑了 300 多分钟 ， 以前只跑了40 分钟么， XXX 你看下呢”。

 我：“果然跑了300多分钟”。 于是哥着手 优化 。  哥最怕 回答   以前快， 现在怎么慢了？      做过优化的都知道，   数据库负载每时每刻 都不同，  数据量也是一样。  这种问题 总 不能 一概 回答 数据量 提升 10倍，  性能下降 100倍吧？？？  后来 哥发现  那个 流程 就是 1个SQL 慢了，性能 至少慢 了500 倍！！！

哥 查询 正在 跑的SQL，  v$session_longops      ， v$session  , v$process  , v$sqlarea   当时哥用了 几个SQL。  其实 哥用好几种 方法关联 到了，  哥为啥 搞几次？？

主要 是为了 方便回答 领导  为啥 以前快， 这次慢的， 呵呵.....    

搞出执行计划   涉及到临时表，  一看 nest loop ，   rows 为1 。  正好 又是大表，  而且还索引回表， 执行计划 就不写了。  反应出   统计信息问题。        再监测一下等待事件，  我靠，临时表空间 读写 频繁，  而且 每次 读写  1 条数据。  查了 临时表  数据来源 ，   查到  有80多万。 

得到 结论：  这个流程慢 主要是 因为   临时表  数据暴增， 导致原来的 执行计划 错误， 而计划中 nest loop   每次往  临时表 空间中写 一条数据， 读一条数据， 数据量有80万。从而使原来 只要 1 分钟的SQL 跑了 300多分钟！！！ 

 找到问题的根源 ，   然后  强制  使用hash  join 。  然后 监测 等待事件 ， 发现 每次 写入 64个数据块，  读出 64 个数据块。 相当于5000 条数据把。  于是 预测SQL 进度 发现  5  6分钟搞定。 

最终整个流程  也在 40 多分钟搞定。     优化完，  （此时 优化完， 但是 哥只是 优化到这一步， 也回答了领导  为啥 以前快， 现在 慢了， 哈哈） 。