亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

  免費(fèi)注冊 查看新帖 |

Chinaunix

  平臺 論壇 博客 文庫
12下一頁
最近訪問板塊 發(fā)新帖
查看: 5746 | 回復(fù): 10
打印 上一主題 下一主題

sybase查詢優(yōu)化的問題 [復(fù)制鏈接]

論壇徽章:
0
跳轉(zhuǎn)到指定樓層
1 [收藏(0)] [報(bào)告]
發(fā)表于 2008-02-04 14:32 |只看該作者 |倒序?yàn)g覽
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分鐘,大家可以分析下嗎?

論壇徽章:
0
2 [報(bào)告]
發(fā)表于 2008-02-04 14:45 |只看該作者

回復(fù) #1 kanfu 的帖子

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

論壇徽章:
0
3 [報(bào)告]
發(fā)表于 2008-02-04 16:05 |只看該作者

回復(fù) #1 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í)行的速度是最慢的,如何解釋?

論壇徽章:
0
4 [報(bào)告]
發(fā)表于 2008-02-04 16:27 |只看該作者

回復(fù) #3 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)化出了什么問題?

論壇徽章:
0
5 [報(bào)告]
發(fā)表于 2008-02-04 16:37 |只看該作者
看where條件是否用到了索引,如果是聚簇索引,其查詢速度在大量數(shù)據(jù)的情況下,優(yōu)勢非常明顯
至于cache size的大小,我認(rèn)為還是越大越好。因?yàn)橐郧敖?jīng)常遇到precedure無法完全執(zhí)行的情況。

論壇徽章:
1
2017金雞報(bào)曉
日期:2017-01-10 15:19:56
6 [報(bào)告]
發(fā)表于 2008-02-04 19:40 |只看該作者
show plan ,dbcc traceon(302) 看一下呢?
還有一個辦法用optdiag statistics 看一下i1表的索引的統(tǒng)計(jì)分布,是否<'301'和>'201'的分別并不一樣

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

論壇徽章:
0
7 [報(bào)告]
發(fā)表于 2008-02-05 00:59 |只看該作者

回復(fù) #6 chuxu 的帖子

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

論壇徽章:
1
2017金雞報(bào)曉
日期:2017-01-10 15:19:56
8 [報(bào)告]
發(fā)表于 2008-02-05 08:36 |只看該作者
這個表上次執(zhí)行updata statistics 或者reorg是什么時候?
索引的統(tǒng)計(jì)分布和數(shù)據(jù)并不是同步更新的,所以數(shù)據(jù)的分布并不能完全等同索引的分布,而查詢策略是根據(jù)索引的統(tǒng)計(jì)分布來處理的。

論壇徽章:
0
9 [報(bào)告]
發(fā)表于 2008-02-15 15:29 |只看該作者
create index on (code2)

論壇徽章:
0
10 [報(bào)告]
發(fā)表于 2008-02-15 16:07 |只看該作者

回復(fù) #9 camham 的帖子

已經(jīng)試過,不行的。
您需要登錄后才可以回帖 登錄 | 注冊

本版積分規(guī)則 發(fā)表回復(fù)

  

北京盛拓優(yōu)訊信息技術(shù)有限公司. 版權(quán)所有 京ICP備16024965號-6 北京市公安局海淀分局網(wǎng)監(jiān)中心備案編號:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年舉報(bào)專區(qū)
中國互聯(lián)網(wǎng)協(xié)會會員  聯(lián)系我們:huangweiwei@itpub.net
感謝所有關(guān)心和支持過ChinaUnix的朋友們 轉(zhuǎn)載本站內(nèi)容請注明原作者名及出處

清除 Cookies - ChinaUnix - Archiver - WAP - TOP