Tout d'abord, assurez-vous de profiler correctement les performances. Par exemple, exécutez la requête deux fois à partir d'ADO.NET et voyez si la deuxième fois est beaucoup plus rapide que la première fois. Cela supprime la surcharge liée à l'attente de la compilation de l'application et de la montée en puissance de l'infrastructure de débogage.
Ensuite, vérifiez les paramètres par défaut dans ADO.NET et SSMS. Par exemple, si vous exécutez SET ARITHABORT OFF dans SSMS, vous constaterez peut-être qu'il s'exécute désormais aussi lentement que lors de l'utilisation d'ADO.NET.
Ce que j'ai trouvé une fois, c'est que SET ARITHABORT OFF dans SSMS provoquait la recompilation du proc stocké et/ou l'utilisation de statistiques différentes. Et soudain, SSMS et ADO.NET signalaient à peu près le même temps d'exécution.
Pour vérifier cela, regardez les plans d'exécution pour chaque exécution, en particulier la table syscacheobjects. Ils seront probablement différents.
L'exécution de 'sp_recompile' sur une procédure stockée spécifique supprimera le plan d'exécution associé du cache, ce qui donnera alors à SQL Server une chance de créer un plan éventuellement plus approprié lors de la prochaine exécution de la procédure.
Enfin, vous pouvez essayer l'approche "nuke it from orbit" consistant à nettoyer l'intégralité du cache de procédure et des tampons de mémoire à l'aide de SSMS :
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
Le faire avant de tester votre requête empêche l'utilisation des plans d'exécution mis en cache et du cache des résultats précédents.
