Najpierw upewnij się, że odpowiednio profilujesz wydajność. Na przykład uruchom zapytanie dwukrotnie z ADO.NET i sprawdź, czy drugi raz jest znacznie szybszy niż pierwszy raz. Eliminuje to narzut związany z oczekiwaniem na skompilowanie aplikacji i zwiększenie infrastruktury debugowania.
Następnie sprawdź ustawienia domyślne w ADO.NET i SSMS. Na przykład, jeśli uruchomisz SET ARITHABORT OFF w programie SSMS, może się okazać, że teraz działa tak wolno, jak podczas korzystania z ADO.NET.
To, co znalazłem kiedyś, to to, że SET ARITHABORT OFF w SSMS spowodował, że przechowywany proces został ponownie skompilowany i/lub użyto innych statystyk. I nagle zarówno SSMS, jak i ADO.NET zgłaszały mniej więcej ten sam czas wykonania.
Aby to sprawdzić, spójrz na plany wykonania dla każdego przebiegu, a konkretnie na tabelę syscacheobjects. Prawdopodobnie będą inne.
Uruchomienie 'sp_recompile' na określonej procedurze składowanej spowoduje usunięcie skojarzonego planu wykonania z pamięci podręcznej, co następnie da SQL Serverowi szansę na stworzenie bardziej odpowiedniego planu przy następnym wykonaniu procedury.
Na koniec możesz wypróbować podejście „nuke it from orbit” polegające na wyczyszczeniu całej pamięci podręcznej procedur i buforów pamięci za pomocą SSMS:
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
Wykonanie tego przed przetestowaniem zapytania uniemożliwia korzystanie z buforowanych planów wykonania i poprzednich wyników w pamięci podręcznej.
