优化SQL到底看什么指标？

nilone

我倒觉得数据仓库中大部分都应该用hash join,OLTP则应该避免。

wang5

我倒觉得数据仓库中大部分都应该用hash join,OLTP则应该避免。

----

这个要按需而定。

DW最常见的查询
dimension table 和 FACT table
再加上一些和时间 区域 产品相关的filter

FACT table一个就 有几百个GB， 甚至TB

等着把它full scan一遍 再hash join ， 花儿都谢了

Yong Huang

原帖由 nilone 于 2010-1-21 00:40 发表
逻辑读是不是需要把查询结果全部读出来才能得到？
如果该查询过程要很久（一个小时），那逻辑读怎么得到？怎么执行优化过程？

If the SQL was run before, as you see in v$sql* views, logical reads (i.e. buffer_gets column) is already available. If it's a new SQL and it doesn't finish running within a reasonable time, as when you're tuning a data warehouse query, then of course you have to rely on other factors, such as calculated cost.

To others,

We're talking about "优化SQL到底看什么指标", not about what execution paths are usually good.

Yong Huang

nilone

YONGHUANG能否提供一个案例，老实说我对consistent read ,buffer gets还没有理解透。set autotrace使用不多。平时优化SQL也就看下执行路径是不是自己期望的，时间是不是快了些，其实谈不上不专业，最终还是要面对一个科学的步骤。

[ 本帖最后由 nilone 于 2010-1-22 08:50 编辑 ]

nilone

原帖由 wang5 于 2010-1-21 20:18 发表
我倒觉得数据仓库中大部分都应该用hash join,OLTP则应该避免。

----

这个要按需而定。

DW最常见的查询
dimension table 和 FACT table
再加上一些和时间 区域 产品相关的filter

FACT table一个就 有几百个GB， 甚至TB

等着把它full scan一遍 再hash join ， 花儿都谢了

我一般考虑把FACT table 过滤字段上建立索引，作为关联的prob表，dimention table作为build表，不会要把FACT table 全表扫描一遍吧。
不知道我的做法是否妥当。

nilone

Yong Huang的意思是：的确是要等一个SQL执行完毕了才获取逻辑读数值吗？你所说的参考其他的计算代价，有没有既定的原则来看？
事实上，我平时面对的主要是DW的批量数据处理。

原帖由 Yong Huang 于 2010-1-22 00:23 发表


If the SQL was run before, as you see in v$sql* views, logical reads (i.e. buffer_gets column) is already available. If it's a new SQL and it doesn't finish running within a reasonable time, as when you're tuning a data warehouse query, then of course you have to rely on other factors, such as calculated cost.

To others,

We're talking about "优化SQL到底看什么指标", not about what execution paths are usually good.

Yong Huang

Yong Huang

> 的确是要等一个SQL执行完毕了才获取逻辑读数值吗？

Yes. But if the SQL runs a long time and you don't want to wait till it finishes, you can always check v$sql* views for the SQL's cumulative buffer_gets at that moment, or v$sesstat for the session's cumulative 'consistent gets' (find statistic# in v$statname or v$sysstat).

> 你所说的参考其他的计算代价，有没有既定的原则来看？

No. But you can always just read the explained plan and see from what step on the cost increases the most. Suppose the plan is like:

operation cost
...
op1          1000
op2          900
op3          10
op4          3

You know you need to focus on op2.

Yong Huang

蓝魔之恋

如果表特别大的话,可以考虑使用分区,可大大减少逻辑读.