Først skal du sikre dig, at du profilerer ydelsen korrekt. Kør for eksempel forespørgslen to gange fra ADO.NET og se, om anden gang er meget hurtigere end første gang. Dette fjerner omkostningerne ved at vente på, at appen kompilerer, og at fejlfindingsinfrastrukturen øges.
Derefter skal du kontrollere standardindstillingerne i ADO.NET og SSMS. For eksempel, hvis du kører SET ARITHABORT OFF i SSMS, kan du opleve, at det nu kører lige så langsomt, som når du bruger ADO.NET.
Hvad jeg fandt engang var, at SET ARITHABORT FRA i SSMS forårsagede, at den lagrede proc blev kompileret og/eller brugt forskellige statistikker. Og pludselig rapporterede både SSMS og ADO.NET nogenlunde den samme eksekveringstid.
For at kontrollere dette, se på udførelsesplanerne for hver kørsel, specifikt syscacheobjects-tabellen. De vil sandsynligvis være anderledes.
Kørsel af 'sp_recompile' på en specifik lagret procedure vil den tilknyttede eksekveringsplan slettes fra cachen, hvilket så giver SQL Server en chance for at lave en muligvis mere passende plan ved næste udførelse af proceduren.
Endelig kan du prøve "nuke it from orbit"-tilgangen med at rense hele procedurecachen og hukommelsesbuffere ved hjælp af SSMS:
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
Hvis du gør det, før du tester din forespørgsel, forhindrer du brug af cachelagrede eksekveringsplaner og tidligere resultatcache.