Snabba upp sql-fråga

5 svar · 371 visningar · startad av Addeladde 7 sep. 2007

AddeladdeMedlem sedan jan. 20013 406 inlägg

Frågan7 sep. 2007 15:15#1

Hej

Jag har en sql-fråga som är skriven för Sybase SQL-Anywhere 9 som ser ut enligt följande:

SELECT AN.PERSONID, A.GRUPP FROM AKTIVITET AS A
LEFT JOIN GRUPP AS G ON A.GRUPP = G.GRUPP
LEFT JOIN KURS AS K ON G.KURS = K.KURS
LEFT JOIN ANSTALLNING AS AN ON A.SIGNBETYG = AN.SIGN
LEFT JOIN UTBILDNING AS U ON A.PERSONID = U.PERSONID
WHERE A.ENHET = 'XX'
AND U.ENHET = 'XX'
AND (U.STOPPDATUM IS NULL OR U.STOPPDATUM > GETDATE())
AND A.STARTDATUM <= GETDATE()-10
AND A.STOPPDATUM >= GETDATE()+10
AND AN.PERSONID IS NOT NULL
AND A.GRUPP IS NOT NULL
GROUP BY AN.PERSONID, A.GRUPP

Den tar dock väldigt väldigt lång tid att köra. Finns det något sätt jag kan snabba upp den på?

Execution plan ger följande resultat

Node Statistics

*
Estimates
*
Description
*
RowsReturned

1.5256

Number of rows returned
PercentTotalCost

99.985

Run time as a percent of total query time
RunTime

0.40253

Time to compute the results
CPUTime

0.16925

Time required by CPU
DiskReadTime

0.23328

Time to perform reads from disk
DiskWriteTime

0

Time to perform writes to disk
DiskRead

194.4

Disk reads
DiskWrite

0

Disk writes

Subtree Statistics

*
Estimates
*
Description
*
RowsReturned

1.5256

Number of rows returned
PercentTotalCost

100

Run time as a percent of total query time
RunTime

0.40259

Time to compute the results
CPUTime

0.16931

Time required by CPU
DiskReadTime

0.23328

Time to perform reads from disk
DiskWriteTime

0

Time to perform writes to disk
DiskRead

194.4

Disk reads
DiskWrite

0

Disk writes

Optimizer statistics

*
Value
*
Description
*
Costed subplans

14

Number of different enumeration strategies considered by the optimizer
Estimated cache pages

64009

Estimated cache pages available for this statement
CurrentCacheSize

523788

Current cache size in kilobytes
Isolation_level

0

Controls the locking isolation level
Optimization_goal

All-rows

Optimize queries for first row or all rows
Optimization_level

9

Reserved
Optimization_workload

Mixed

Controls whether optimizing for OLAP or mixed queries
ProductVersion

9.0.2.2451

Product version
User_estimates

Override-magic

Controls whether to respect user estimates

Select list
AN.PERSONID

char(11)
A.GRUPP

char(20)

LarsGMedlem sedan dec. 200012 464 inlägg

9 sep. 2007 15:09#2

Varför har du left join då du ändå ställer villkor på de högra tabellerna i din where-klausul?

Se till att de kolumner som finns i join-villkoren är indexerade. Förmodligen kan index på enhet också hjälpa.

AddeladdeMedlem sedan jan. 20013 406 inlägg

9 sep. 2007 18:20#3

Vad gör det för skillnad om jag byter från left join till outer join?
Jag ställer ju frågor på flera tabeller.

Tyvärr kan jag inte skapa index då jag bara har läsrättigheter på databasen tyvärr.

LarsGMedlem sedan dec. 200012 464 inlägg

10 sep. 2007 07:59#4

En left join är en (av tre varianter av) outer join. Jag menade att du skulle byta till inner join (och ta bort villkoren med is not null), eftersom det i alla fall blir samma resultat med dina nuvarande where-villkor.

Utan vettiga index kan du aldrig få någon bra prestanda om du inte har små datamängder.

AddeladdeMedlem sedan jan. 20013 406 inlägg

10 sep. 2007 08:09#5

Om vi nu får adminrättigheter och sätter några index så kan det inte göra att något i andra applikationer som använder databasen börjar fungera annorlunda?

spangoMedlem sedan juni 20008 205 inlägg

10 sep. 2007 08:27#6

Ja, insert/delete/update av indexerade fält är normalt långsammare än på oindexerade fält. Men att foreign keys inte är indexerade låter nästan som en bugg i mina öron. Tanken är ju att man ska joina på sådana fält, och om man inte har index när man gör joins blir det segt.