sql >> Databasteknik >  >> RDS >> Sqlserver

Parameter Sniffing (eller Spoofing) i SQL Server

FYI - du måste vara medveten om något annat när du arbetar med SQL 2005 och lagrade processer med parametrar.

SQL Server kommer att kompilera den lagrade processens exekveringsplan med den första parametern som används. Så om du kör detta:

usp_QueryMyDataByState 'Rhode Island'

Utförandeplanen kommer att fungera bäst med en liten stats data. Men om någon vänder sig om och springer:

usp_QueryMyDataByState 'Texas'

Utförandeplanen utformad för data i Rhode Island-storlek kanske inte är lika effektiv med data i Texas. Detta kan ge överraskande resultat när servern startas om, eftersom den nyligen genererade exekveringsplanen kommer att riktas mot vilken parameter som helst som används först - inte nödvändigtvis den bästa. Planen kommer inte att kompileras om förrän det finns en stor anledning att göra det, som om statistik byggs om.

Det är här frågeplaner kommer in, och SQL Server 2008 erbjuder många nya funktioner som hjälper DBA:er att fästa en viss frågeplan på plats på lång sikt oavsett vilka parametrar som anropas först.

Min oro är att när du byggde om din lagrade proc, tvingade du utförandeplanen att kompileras om. Du anropade det med din favoritparameter, och då gick det naturligtvis snabbt - men problemet kanske inte var den lagrade proc. Det kan ha varit så att den lagrade proc:n kompilerades om någon gång med en ovanlig uppsättning parametrar och därmed en ineffektiv frågeplan. Du kanske inte har fixat någonting, och du kan möta samma problem nästa gång servern startar om eller frågeplanen kompileras om.



  1. Hur man kör en lagrad procedur i C#-programmet

  2. Hur man får arbetsdagar eller timmar mellan två datum

  3. 2 sätt att ta reda på vilket kvartal en dejt tillhör i MariaDB

  4. Förhindra dropptabell vid målschema i Oracle Streams