Uw code in SSMS is niet dezelfde code die u in uw toepassing uitvoert. Deze regel in uw toepassing voegt een NVARCHAR-parameter toe:
ada.SelectCommand.Parameters.AddWithValue("@clientID", ClientID);
terwijl je het in het SSMS-script declareert als VARCHAR:
declare @clientID varchar(200)
Vanwege de regels van gegevenstypevoorrang is de Where client_id = @clientID uitdrukking in uw zoekopdracht is niet geschikt voor SARG waar @clientID is van het type NVARCHAR (ik maak een sprong in het diepe en neem aan dat client_id kolom is van het type VARCHAR). De applicatie dwingt dus een tabelscan af waarbij de SSMS-query een snelle sleutelzoekopdracht kan uitvoeren. Dit is een algemeen bekend en begrepen probleem bij het gebruik van Parameters.AddWithValue en is al eerder in veel artikelen besproken, bijvoorbeeld. zie Hoe gegevenstoegangscode de databaseprestaties beïnvloedt. Als het probleem eenmaal is begrepen, zijn de oplossingen triviaal:
-
voeg parameters toe met de constructor die een type accepteert:
Parameters.Add("@clientID", SqlDbType.Varchar, 200)(en doe geef de expliciete lengte door om cache-vervuiling te voorkomen, zie Query-prestaties en plan cache-problemen wanneer de parameterlengte niet correct is opgegeven -
of cast de parameter in de SQL-tekst:
where client_id = cast(@clientID as varchar(200)).
De eerste oplossing is superieur omdat het het cache-vervuilingsprobleem oplost naast het SARG-ability-probleem.
Ik zou je ook aanraden om Slow in the Application, Fast in SSMS? Prestatiemysteries begrijpen