Jag sitter pa ett (o)trevligt litet problem med en applikation jag arvt.

Applikationen skickar med jamna mellanrum en fraga till databasen (SQL Server 2000) dar ett antal parametrar skickas in. En av dessa parametrar ar faktiskt en strang som ar en full WHERE-klausul, och darfor ser den lagrade proceduren ut som en lang strang som konkatenerar ihop allting till en SQL frag som sedan kors med hjalp av

<code>
EXEC @QueryString
</code>

Nu ar det sa att denna fraga ar inte direkt snabb, och det hjalps inte av att eftersom sql-fragan skapas genom konkatenering anvands inga parametrar och det skapas ingen vettig exekveringsplan som kan ateranvandas. Eftersom det ar en standdigt aterkommande fraga (kommer med jamna mellanrum fran alla anslutna anvandare) sa far databasen jobba onodigt mycket.

Exempel pa hur det ser ut nu:
<code>
DECLARE @Query VARCHAR(4000)
SET @Query = 'SELECT * FROM tbl WHERE Company = ' + @CompanyID + ' AND ' + @WhereClause';'
EXEC @Query
</code>

Ar det ens lont att undersoka mojligheten att parametisera ut @CompanyID? Kommer fragan att skapa en dynamisk exekveringsplan for den delen av fragan och sedan kora kvarvarande del icke optimerat?
Eller forstor den icke-parametiserade delen fragan helt och hallet?

Finns det kanske ett mycket battre satt att gora det pa som jag helt glomt bort?
Andledningen till att det skickas in en farding WHERE-klausul ar att den kan ha ett dynamiskt antal kriterier och samma kriterie (falt) kan fore komma flera ganger.

Hjalp?

Du har antaligen mycket data och saknar index på något fält som används i villkoret.
Parametrisering och exekveringsplan är väl bra men det gör troligen inga underverk för prestandan.

Problemet ar att fragan joinar 7-8 tabeller och da den dynamiska WHERE-klausulen kan vara pa i princip vilket falt som helst (den oversatter ett filter som gar att satta i UI:et) sa har in de falten nagot index. Att lagga till en massa index kommer att forstora prestandan for andra fragor da tabellerna andras ganska friskt.

At ha en bra exekveringplan gor definitivt en del for prestandan. Kor du samma SQL fraga 1 gang och det tar 2 sek, sen kor den direkt igen sa tar den <1 sek. Detta pga SQL Server har exekveringsplanen i minnet. Om du 'hardkodar' parametrarna blir samma fraga langsam igen om du andrar varde i parametern.

Det går ju iofs att göra det parametriserat och dynamiskt samtidigt.

Om parametern "P1" ska med:

1. Appenda " AND " & P1Namnet & " = @P1 "
2. Lägg till parametern "@P1", P1Vardet

(detta loopas så nästa varv heter den P2 osv)

Ett annat trix som tillåter dynamiska formulär som anropar en SP,
är att skapa villkoret så här:
WHERE Special=@Specialfield OR LEN(@Specialfield) = 0
(så om @Specialfield inte anges så är inte detta med i villkoret)

ingen dum idé faktiskt...

Får testa att laborera lite med det och återkomma.