Zorg er eerst voor dat u de prestaties goed profileert. Voer de query bijvoorbeeld twee keer uit vanuit ADO.NET en kijk of de tweede keer veel sneller is dan de eerste keer. Dit elimineert de overhead van het wachten tot de app is gecompileerd en de foutopsporingsinfrastructuur wordt uitgebreid.
Controleer vervolgens de standaardinstellingen in ADO.NET en SSMS. Als u bijvoorbeeld SET ARITHABORT OFF uitvoert in SSMS, zult u merken dat het nu net zo traag werkt als bij het gebruik van ADO.NET.
Wat ik ooit ontdekte was dat SET ARITHABORT OFF in SSMS ervoor zorgde dat het opgeslagen proces opnieuw werd gecompileerd en/of andere statistieken werden gebruikt. En plotseling rapporteerden zowel SSMS als ADO.NET ongeveer dezelfde uitvoeringstijd.
Om dit te controleren, kijkt u naar de uitvoeringsplannen voor elke uitvoering, met name de tabel syscacheobjects. Ze zullen waarschijnlijk anders zijn.
Als u 'sp_recompile' uitvoert op een specifieke opgeslagen procedure, wordt het bijbehorende uitvoeringsplan uit de cache verwijderd, waardoor SQL Server de kans krijgt om een mogelijk geschikter plan te maken bij de volgende uitvoering van de procedure.
Ten slotte kunt u de "nuke it from orbit"-benadering proberen om de volledige procedurecache en geheugenbuffers op te schonen met behulp van SSMS:
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
Als u dit doet voordat u uw zoekopdracht test, voorkomt u het gebruik van in de cache opgeslagen uitvoeringsplannen en eerdere resultatencache.