这个sql怎么优化!

askgyliu

这个UNIQUE INDEX + INCLUDE不知道能不能用在FILTERING来提升性能。

比如说，一个TABLE_1(F1 CHAR(10)， F2 CHAR(10)， F3 NUMBER)

UNIQUE INDEX(F1)。

但是若是一个SQL是这样的：

select f1, f3
from table_1
where f2='some value'
order by f1

若是有一个INDEX是这样的：

create unique index idx_1 on table_1(f1) includes (f2, f3)

那么这个INDEX是不是就可以满足这个QUERY了呢？DB2是不是懂得只用这个INDEX，并且不用SORTING了呢？

下面这个INDEX也是可能对前面的QUERY有帮助：

create unique index idx_2 on table_1(f1,f2, f3)

只是这个INDEX会增加不必要的BRANCH LEVEL和LEAF PAGE。

myfriend2010

原帖由 askgyliu 于 2008-5-25 13:58 发表


可以详细地给些测试时的设定吗？

DMS TEMP Vs SMS TEMP?

DMS Permanent Vs SMS Permanent?

注意测试时每次换，并且只换一个条件。

1.SMS space:

CREATE TABLESPACE "USERADDSP"
  IN DATABASE PARTITION GROUP "IBMDEFAULTGROUP"
  PAGESIZE 4K
  MANAGED BY SYSTEM
  USING
   ('C:db2USERADDSPcont0'
   )
     ON DBPARTITIONNUM (0)
  USING
   ('C:db2USERADDSPcont1'
   )
     ON DBPARTITIONNUM (1)
  USING
   ('C:db2USERADDSPcont2'
   )
     ON DBPARTITIONNUM (2)
  USING
   ('C:db2USERADDSPcont3'
   )
     ON DBPARTITIONNUM (3)
  EXTENTSIZE 16
  PREFETCHSIZE 16
  BUFFERPOOL "IBMDEFAULTBP"
  OVERHEAD 10.50
  TRANSFERRATE 0.14
  DROPPED TABLE RECOVERY OFF;


2.DMS space:

CREATE TABLESPACE "TESTTBS"
  IN DATABASE PARTITION GROUP "IBMDEFAULTGROUP"
  PAGESIZE 4K
  MANAGED BY DATABASE
  USING
   (File 'G:        esttbcout0' 524288
   )
     ON DBPARTITIONNUM (0)
  USING
   (File 'G:        esttbcout1' 524288
   )
     ON DBPARTITIONNUM (1)
  USING
   (File 'G:        esttbcout2' 524288
   )
     ON DBPARTITIONNUM (2)
  USING
   (File 'G:        esttbcout3' 524288
   )
     ON DBPARTITIONNUM (3)
  EXTENTSIZE 16
  PREFETCHSIZE 16
  BUFFERPOOL "IBMDEFAULTBP"
  OVERHEAD 10.50
  TRANSFERRATE 0.14
  DROPPED TABLE RECOVERY OFF;

我在这2个不同的表空间分别创建了2个表!然后测试SQL分别插入这2个表的

myfriend2010

==测试下include

myfriend2010

include 应该不行的,include的列有限制:

maxinum number of index columns is 16

myfriend2010

直接创建index 也有这个问题,索引列不能太长!

DBA00017E - maxinum number of index columns is 16

wangzhonnew

then yeah it could be not useful to use index, because using index is possible to avoid SORT, however if the number of rows selected is almost all rows in the table and the index does NOT include all required columns, it then requires FETCH which may increase the cost a lot by using additional IO to get data...

so in this case, try to reorg data based on the join column, hopefully it will reduce the time used to sort data, and maybe creating clustered index on the join column is also good to have