DB2 Sql性能优化

[qingyuan18]

各位高人，有一个奇怪的问题：
我的sql是几个表的关联查询，类似：
select tab1.col1,tab2.col1,tab2.col2,tab3.colX,tab3.colY
from tab1,tab2,tab3
where tab1.colX=tab2.colY and tab2.colY=tab3.colY
and tab1.xxx.....

由于tab1是很大数据量的表，原来的查询很耗时，为了优化，将tab1单独提出来做成sub-query的形式：
select
innerTab.col1,tab2.col2,tab3.colX....
from
tab2,tab3
(select tab1.col1 from tab1 where tab1.XXX....)As innerTab
where tab2.colY=innerTab.XXX

现在发现innerTab可以跑出来，但是跟其他tab放在一起join就跑不出，而且db2explan显示的执行策略也没有变化，这是怎么回事？难道innerTab不应该是单独的执行策略么？

[zhaojianmi1]

db2的优化器很强大，可以吧子查询转化成连接

需要做的是建好索引，提供最新的统计信息，让db2自己计算出执行计划

[yangxiao_jiang]

reorg一下表，看看执行计划是否会更新。

[jirunlin]

做下runstats，好处是谁用谁知道哇

[qingyuan18]

2楼的回答是对的，经实验发现，子查询在DB2自己的优化器前是会被自动转化的

现在性能已经优化到了20分钟左右，接下来的优化集中在怎么把NLJOIN转化成HAJOIN，这个麻烦了，因为两个关联查询的表没有相同名字的字段，DB2优化器一般是两个字段相同的表关联时才会用HashJoin

[zhaojianmi1]

你启用了第几层优化级别，低层次的优化级别不支持哈希连接

[plusplus2010]

字段名字不需要相同，哈希连结的前提是连结谓词中只出现"＝"（而非<,>,等）。针对lz的问题，直接把子查询变成"Materialized View"也许更好。

[zhaojianmi1]

优化级别5以上，db2优化器才会选择哈希连接
http://www.ibm.com/developerworks/cn/data/library/techarticles/0208zubiri/0208zubiri.html

[qingyuan18]

MQT涉及到数据库变更，那是最后的方案，现在领导还是想先从sql入手，改变join和高能耗的操作方式

优化级别是2： Query Optimization Class = 2 已经比较高了，这个也涉及数据库的变更，因为变了所有其他的查询的级别都会变

[qingyuan18]

问题似乎解决了，奇怪的是我只是修改了一下from下面表的顺序，和where条件的先后顺序以及左右列顺序，DB2的执行策略就变了.......


稀里糊涂的，反正现在可以在10分钟内跑出来了，满足他们的需求了

[zhaojianmi1]

[Quote=引用 11 楼 qingyuan18 的回复:]
问题似乎解决了，奇怪的是我只是修改了一下from下面表的顺序，和where条件的先后顺序以及左右列顺序，DB2的执行策略就变了.......


稀里糊涂的，反正现在可以在10分钟内跑出来了，满足他们的需求了
[/Quote]