Първо, уверете се, че профилирате правилно производителността. Например, стартирайте заявката два пъти от ADO.NET и вижте дали вторият път е много по-бърз от първия. Това премахва излишните разходи за изчакване приложението да се компилира и инфраструктурата за отстраняване на грешки да се увеличи.
След това проверете настройките по подразбиране в ADO.NET и SSMS. Например, ако стартирате SET ARITHABORT OFF в SSMS, може да откриете, че сега работи толкова бавно, колкото при използване на ADO.NET.
Това, което открих веднъж, беше, че SET ARITHABORT OFF в SSMS доведе до прекомпилиране на съхранената процедура и/или използване на различни статистически данни. И изведнъж и SSMS, и ADO.NET отчитаха приблизително едно и също време на изпълнение.
За да проверите това, вижте плановете за изпълнение за всяко изпълнение, по-специално таблицата syscacheobjects. Вероятно ще бъдат различни.
Изпълнението на 'sp_recompile' на конкретна съхранена процедура ще изхвърли свързания план за изпълнение от кеша, което след това дава шанс на SQL Server да създаде евентуално по-подходящ план при следващото изпълнение на процедурата.
И накрая, можете да опитате подхода „изстрелване от орбита“ за почистване на целия кеш на процедурата и буфери на паметта с помощта на SSMS:
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
Това, преди да тествате заявката си, предотвратява използването на кеширани планове за изпълнение и кеш на предишни резултати.
