sql >> Databasteknik >  >> RDS >> Sqlserver

Parametern fungerar inte lika bra som att hårdkoda värdet

REDIGERA SAMMANFATTNING På begäran från Damien_The_Unbeliever

Målet är att få bästa/mest information om variabelvärdet till SQL INNAN planen skapas, i allmänhet gör parametersniffning detta. Det kan finnas en anledning till att parametersniffning "inaktiverades" i det här fallet. Utan att se en bättre representation av den faktiska koden kan vi inte riktigt säga vad lösningen är eller varför problemet finns. Prova sakerna nedan för att tvinga de drabbade områdena att skapa planer med faktiska värden.

*LÅNG VERSION MED MER DETALJER *

Är detta din faktiska lagrade proc? Har du standardvärden för dina parametrar? Om så är fallet, vilka är de?

Parametersniffning kan hjälpa - men det måste ha typiska parametervärden för att skapa planen bra, och om inte, kommer det inte att hjälpa eller skapa en dålig plan baserad på det icke-typiska parametervärdet. Så om en variabel har ett standardvärde på null eller ett värde som inte är ett typiskt värde första gången den körs och planen kompileras - skapar den en dålig plan.

Om någon annan skrev denna sproc - de kan ha avsiktligt "inaktiverat" parametersniffning med de lokala variablerna av en anledning. Affärsregler kan kräva dessa variabla strukturer.

Målet är att få bästa/mest information om variabelvärdet till SQL INNAN planen skapas, och i allmänhet gör Parameter Sniffing detta. Men det finns saker som kan få det att påverka prestandan negativt, och det kan vara därför det är "inaktiverat". Det verkar fortfarande som att planen skapas med atypiska värden för parametrarna eller inte tillräckligt med information fortfarande - med parametersniffning eller inte.

Försök anropa frågan inuti sproc med Använd sp_executesql för att köra de berörda frågorna, tvinga den att generera en plan för det området med de faktiska variablerna och se om det är bättre. Detta kan vara din lösning om du måste ha den här typen av oregelbundna parametervärden - skapa lagrade processer som kör de berörda delarna och anropar dem senare från den lagrade proceduren - efter att variabeln har fått ett typiskt värde.

Utan att se en bättre representation av den faktiska koden är det svårt att se vad problemet är. Förhoppningsvis hjälper den här informationen -



  1. java - DataSource för fristående applikation - ingen applikationsserver

  2. Filtrera på ett alias i mysql

  3. Fråga efter MySQL:s INFORMATIONSSCHEMA:Varför? På vilket sätt?

  4. En datetime-motsvarighet i java.sql? (finns det en java.sql.datetime?)