多表连接时,为何走表扫描

    恩,I/O确实存在问题,接手这套系统的时候已经跑了五六年,规划之初客户就把很多高访问的容器堆在两个riad10上,日志也都在这上面.
上面batch抓出来的信息是在每周最繁忙的时候,这个时候汇总大量数据,这一块确实有调优的空间.收起

回复 28# mdkii


    mkdii您好,
现在发现,很多表连接都有这个问题
select t1.c1,t2.c1 from t1,t2 where t1.c2=t2.c2 and t1.c3=t2.c3 and t2.c4='aaa'

类似这样的SQL,t1和t2连接时多于一个条件,t2有本地谓词
t1都走表扫描,这个除了修改SQL,还有别的办法处理吗收起

    是的,IO瓶颈是正确的.
这是周五下午的统计,同步结算等操作大量堆积.主要集中在两个raid10上,8块磁盘上收起

从db2batch来看，你得系统比较忙。
而且io是瓶颈。一次 physical reads 需要17、8毫秒，有的高达20多毫秒。
你关注一下你的磁盘是不是过于busy了。
可能你该跟存储的人讨论一下是不是磁盘划分得不合理。收起

回复 25# leo


    恩,大师说的有道理,这样做确实不太合理,希望有其他解决办法收起

    第一遍没有输出到文件,使用的时间是
Type      Number      Repetitions Total Time (s) Min Time (s)   Max Time (s)   Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output
--------- ----------- ----------- -------------- -------------- -------------- --------------- -------------- -------------- -------------
Statement           1           1     214.110131     214.110131     214.110131      214.110131     214.110131              0             0

* Total Entries:              1
* Total Time:               214.110131 seconds
* Minimum Time:             214.110131 seconds
* Maximum Time:             214.110131 seconds
* Arithmetic Mean Time:     214.110131 seconds
* Geometric Mean Time:      214.110131 seconds
---------------------------------------------
* Timestamp: Fri Jun 21 2013 17:26:13 BEIST


第二遍输出到文件中,文件见附件.



谢谢各位大神:)收起

这样创建索引，包含查询和选择的所有列，当然走索引扫描了

但我担心这样随便加索引导致表的索引过多，维护困难收起

走index only是可以减少cost。
但为专门的select字段定制索引会导致索引变得很多。
从原先的计划看，虽然有个表扫描，但不应该需要20S这么久。
你可以把db2batch -o p 5的结果发上来看看。收起

回复 22# xu5762173


看到IO cost明显下降.    very good update! tks !收起

测试环境下,完整SQL也使用到了索引,

生产环境,等维护时间再尝试.

条件中的列被层层包含使用,看来也得注意收起