Oracle 临时表之临时表的应用问题

网上有人给出了最佳的优化思路是： 1.先将大表中满足条件的记录抽出来生成一张临时表. 2.再将这较小的临时表与另一张较小的表进行

网上有人给出了最佳的优化思路是：

1.先将大表中满足条件的记录抽出来生成一张临时表.

2.再将这较小的临时表与另一张较小的表进行关联查询.

先不论思路是否值得商榷，这把临时表当成中转站的做法还是很值得肯定

临时表本质上就是一种cache的表现形式，Oracle的临时表都是事先建好的

一旦用了临时表，存放的就是和本会话相关的数据

没有人会傻乎乎地用临时表来保存本应该共享的数据

with子查询实际上也是用了临时表，Oracle会替你创建一张临时表

因此临时表的开销WITH子查询也会有。只要把AUTOTRACE打开你就会看到REDO的开销

关于临时表的使用至少会带来两个问题：

1）主查询的执行计划问题

2）额外的写redo的问题

如果，

临时表作为复杂查询条件的中间结果用于主查询，因为临时表里往往只是个别字段的少量数据，1）的问题比较突出；

如果，

临时表作为最终展现前的结果归集，可能临时表会有比较多字段的较多数据，2）的问题比较突出

㈠ 主查询的执行计划问题

PHP经典实例(第二版)

PHP经典实例（第2版）能够为您节省宝贵的Web开发时间。有了这些针对真实问题的解决方案放在手边，大多数编程难题都会迎刃而解。《PHP经典实例(第2版)》将PHP的特性与经典实例丛书的独特形式组合到一起，足以帮您成功地构建跨浏览器的Web应用程序。在这个修订版中，您可以更加方便地找到各种编程问题的解决方案，《PHP经典实例(第2版)》中内容涵盖了：表单处理；Session管理；数据库交互；使用We

453

查看详情

9i临时表由于动态采样level 1,还得用hint,10g比较好用

比较复杂的存储过程（比如数据抽取）可能用到临时表，比实体表优势就是redo少，，自动清除

对于临时表的缺陷--采样问题，执行计划的问题其实主要是临时表的cardinality的问题

对于临时表方案，建议动态采样。9IR2以后的版本使用DYNAMIC_SAMPLING 参数或hint能基本避免

如写上 HINT强制它采样 /*+dynamic_sampling(t 0) */

cardinality hint分段提示是个比较好的最佳实践

例如：

临时表里的数据量有大起大落的情形，Oracle只会在硬解析的时候做一次取样

当临时表数据量变化之后，原来的执行计划可能已经不是最优的

碰到这种问题建议使用动态SQL

临时表的数据量在插入结束之后可以通过SQL%ROWCOUNT得知

然后在动态SQL里面拼入cardinality提示，这个提示没有必要精确，要不然你就会有无数的硬解析了

建议给它设置的坎是5000, 即1-5000当作5000处理，5001-10000当作10000,

如此类推，CARDINALITY = CEIL(SQL%ROWCOUNT/5000)*5000，

你也可以通过测试调整出一个合理的值