sybase查詢優(yōu)化的問(wèn)題

kanfu

ASE12.0.0.8/P/EBF 12452 ESD4/NT (IX86)
1G的Default data cache
100M的tempdb cache ,綁定了tempdb.
tempdb的大小是1000M data , 500M log

我有一個(gè)查詢時(shí)6表關(guān)聯(lián)，表之間都是通過(guò)主鍵關(guān)聯(lián)的，每個(gè)表的數(shù)據(jù)在6-10萬(wàn)之間,所有的查詢用到的表都已經(jīng)綁定到了Default data cache
。沒(méi)有附件其它條件的時(shí)候一切正常，查詢的結(jié)果集大約是6萬(wàn)條記錄；附加一個(gè)條件，條件的右邊是一個(gè)常量，通過(guò)sp_showplan可以看出條件用上索引了；現(xiàn)在的問(wèn)題調(diào)整常量，當(dāng)結(jié)果集在2萬(wàn)以下速度非�？�，大約15秒,當(dāng)調(diào)整常量值導(dǎo)致結(jié)果集在2萬(wàn)以上的查詢，速度非常慢，需要10分鐘，大家可以分析下嗎？

kanfu

如果解釋在某種情況下用上索引比全表掃描更慢？
我用dbcc   traceon(3604,302)，看優(yōu)化數(shù)據(jù)庫(kù)的過(guò)程，發(fā)現(xiàn)其優(yōu)化過(guò)程是一樣的。所以很難理解為什么性能上會(huì)有這么大的差異？

kanfu

繼續(xù)研究，問(wèn)題好像有點(diǎn)意思：
說(shuō)明：表Item1和Item2的主鍵列都是code1,code2和code3，在Item1表的code2,code3上建立了一個(gè)索引，下面是3個(gè)SQL
SQL1：
select convert(varchar(20),getdate(),109)
SELECT count(*) FROM Item1 i1, Item2 i2
WHERE        i1.code1 = i2.code1 and i1.code2 = i2.code2 and i1.code3 = i2.code3
select convert(varchar(20),getdate(),109)
go
SQL2：
select convert(varchar(20),getdate(),109)
SELECT count(*) FROM Item1 i1, Item2 i2
WHERE        i1.code1 = i2.code1 and i1.code2 = i2.code2 and i1.code3 = i2.code3 and i1.code2 < '201'
select convert(varchar(20),getdate(),109)
go
SQL3：
select convert(varchar(20),getdate(),109)
SELECT count(*) FROM Item1 i1, Item2 i2
WHERE        i1.code1 = i2.code1 and i1.code2 = i2.code2 and i1.code3 = i2.code3 and i1.code2 >= '201'
select convert(varchar(20),getdate(),109)
go

第1個(gè)SQL的執(zhí)行結(jié)果為：
Feb  4 2008  4:05:52
       71141
Feb  4 2008  4:05:54
第2個(gè)SQL的執(zhí)行結(jié)果為：
Feb  4 2008  4:05:54
       17707
Feb  4 2008  4:06:22
第3個(gè)SQL的執(zhí)行結(jié)果為：
Feb  4 2008  4:06:22
       53434
Feb  4 2008  4:06:23

以上數(shù)據(jù)測(cè)試多次，包括調(diào)整SQL的執(zhí)行次序等，結(jié)果和上面的基本一致。
結(jié)果分析，第2個(gè)SQL行數(shù)最少，結(jié)果執(zhí)行的速度是最慢的，如何解釋?zhuān)?/td>

kanfu

繼續(xù)更新條件測(cè)試：
SQL4:
select convert(varchar(20),getdate(),109)
SELECT count(*) FROM Item1 i1, Item2 i2
WHERE        i1.code1 = i2.code1 and i1.code2 = i2.code2 and i1.code3 = i2.code3 and i1.code2 < '301'
select convert(varchar(20),getdate(),109)
go
SQL5：
select convert(varchar(20),getdate(),109)
SELECT count(*) FROM Item1 i1, Item2 i2
WHERE        i1.code1 = i2.code1 and i1.code2 = i2.code2 and i1.code3 = i2.code3 and i1.code2 >= '301'
select convert(varchar(20),getdate(),109)
go
SQL6：
select convert(varchar(20),getdate(),109)
SELECT count(*) FROM Item1 i1, Item2 i2
WHERE        i1.code1 = i2.code1 and i1.code2 = i2.code2 and i1.code3 = i2.code3 and i1.code2 > '102'
select convert(varchar(20),getdate(),109)
go
SQL7：
select convert(varchar(20),getdate(),109)
SELECT count(*) FROM Item1 i1, Item2 i2
WHERE        i1.code1 = i2.code1 and i1.code2 = i2.code2 and i1.code3 = i2.code3 and i1.code2 <= '102'
select convert(varchar(20),getdate(),109)
go
結(jié)果集：
第4個(gè)SQL的執(zhí)行結(jié)果為：
Feb  4 2008  4:19:54
       65309
Feb  4 2008  4:23:20
第5個(gè)SQL的執(zhí)行結(jié)果為：
Feb  4 2008  4:23:20
        5832
Feb  4 2008  4:23:20
第6個(gè)SQL的執(zhí)行結(jié)果為：
Feb  4 2008  4:30:26
       59387
Feb  4 2008  4:30:27
第7個(gè)SQL的執(zhí)行結(jié)果為:
Feb  4 2008  4:32:11
      11754
Feb  4 2008  4:32:17
結(jié)果分析,用大于的查詢速度明顯要用小于的查詢速度快，Sybase的優(yōu)化出了什么問(wèn)題？

ljb222521

看where條件是否用到了索引，如果是聚簇索引，其查詢速度在大量數(shù)據(jù)的情況下，優(yōu)勢(shì)非常明顯
至于cache size的大小，我認(rèn)為還是越大越好。因?yàn)橐郧敖?jīng)常遇到precedure無(wú)法完全執(zhí)行的情況。

chuxu

show plan ，dbcc traceon(302) 看一下呢？
還有一個(gè)辦法用optdiag statistics 看一下i1表的索引的統(tǒng)計(jì)分布，是否<'301'和>'201'的分別并不一樣

[ 本帖最后由 chuxu 于 2008-2-4 19:43 編輯 ]

kanfu

Item1,code2各值得記錄數(shù)量
101             4441
102             7313
103             2935
104             3018
201             7409
202             6177
203             6834
204            11136
205             6733
206             8277
207             1036
301              774
302              723
303              117
304              507
305               10
401              548
402              555
501              631
502              337
601             1070
701              479
702               81

chuxu

這個(gè)表上次執(zhí)行updata statistics 或者reorg是什么時(shí)候？
索引的統(tǒng)計(jì)分布和數(shù)據(jù)并不是同步更新的，所以數(shù)據(jù)的分布并不能完全等同索引的分布，而查詢策略是根據(jù)索引的統(tǒng)計(jì)分布來(lái)處理的。

camham

create index on (code2)

kanfu

已經(jīng)試過(guò)，不行的。