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

kanfu

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

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

kanfu

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

kanfu

繼續(xù)研究，問題好像有點(diǎn)意思：
說明：表Item1和Item2的主鍵列都是code1,code2和code3，在Item1表的code2,code3上建立了一個索引，下面是3個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個SQL的執(zhí)行結(jié)果為：
Feb  4 2008  4:05:52
       71141
Feb  4 2008  4:05:54
第2個SQL的執(zhí)行結(jié)果為：
Feb  4 2008  4:05:54
       17707
Feb  4 2008  4:06:22
第3個SQL的執(zhí)行結(jié)果為：
Feb  4 2008  4:06:22
       53434
Feb  4 2008  4:06:23

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

kanfu

繼續(xù)更新條件測試：
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個SQL的執(zhí)行結(jié)果為：
Feb  4 2008  4:19:54
       65309
Feb  4 2008  4:23:20
第5個SQL的執(zhí)行結(jié)果為：
Feb  4 2008  4:23:20
        5832
Feb  4 2008  4:23:20
第6個SQL的執(zhí)行結(jié)果為：
Feb  4 2008  4:30:26
       59387
Feb  4 2008  4:30:27
第7個SQL的執(zhí)行結(jié)果為:
Feb  4 2008  4:32:11
      11754
Feb  4 2008  4:32:17
結(jié)果分析,用大于的查詢速度明顯要用小于的查詢速度快，Sybase的優(yōu)化出了什么問題？

ljb222521

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

chuxu

show plan ，dbcc traceon(302) 看一下呢？
還有一個辦法用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

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

camham

create index on (code2)

kanfu

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