OZ wrote:
>
> "Kristian Damm Jensen" <kristian-damm.jensenRE@MOVEcgey.com> skrev:
>
> > Ikke korrekt. Enhver DB-forespørgsel kræver at der dannes en query-plan.
> > Når forespørgslen ligger i en SP, dannes denne query-plan første gang
> > SPen køres, og lagres derefter sammen med SPen, med det resultat at du
> > sparer tid til dannelsen af en query-plan ved senere udførelser.
>
> Det er jo derfor jeg er forvirret, jeg syntes også det burde være
> hurtigere..... Men-
> Hvordan forklarer du så, at det går langsommere at bruge en SP der
> indeholder en simpel select VS et direkte simpel select kald??
>
> Jeg er bare nysgerrig..
Også mig.
Det var sådan set derfor jeg ikke svarede på den oprindelige
forespørgsel - jeg kunne ikke komme med nogen god forklaring.
Men det ses af og til, at der bliver lavet en dårlige query-plan, når
den skal laves generisk (...where felt = @vaerdi) frem for specifik (...
where felt = 5). Uden en nærmere analyse, er det svært at sige hvorfor.
En forklaring kan være at query-planen bliver lavet på baggrund af de
data, der er til rådighed på det tidspunkt. Jeg taler her om såvel
parametre til proceduren som statistics i basen.
Hvis disse ligger på en måde, så det fx ikke kan betale sig at bruge
index, vil alle efterfølgende kørsler af den samme procedure heller ikke
bruge index. I så tilfælde skal man (1) køre en update statistics på de
relevante tabeller (2) køre en sp_recompile på SPen (eller er det
overflødigt efter (1)? Det kan jeg ikke huske.) (3) sørge for at vælge
en værdi til den første kørsel, der sikrer sig at index kan betale sig
(og ikke en værdi, der dækker over 20-50% af rækkerne i tabellen).
Men der kan være mange andre grunde, og det vil som sagt kræve en
nærmere analyse, at sige, hvad der er galt i dit tilfælde.
--
Kristian Damm Jensen | Feed the hungry at
www.thehungersite.com
kristian-damm.jensen@cgey.dk | Two wrongs doesn't make a right,
ICQ# 146728724 | but three lefts do.