En primer lugar, asegúrese de perfilar el rendimiento correctamente. Por ejemplo, ejecute la consulta dos veces desde ADO.NET y vea si la segunda vez es mucho más rápida que la primera. Esto elimina la sobrecarga de esperar a que se compile la aplicación y se active la infraestructura de depuración.
A continuación, verifique la configuración predeterminada en ADO.NET y SSMS. Por ejemplo, si ejecuta SET ARITHABORT OFF en SSMS, es posible que ahora se ejecute tan lentamente como cuando usa ADO.NET.
Lo que encontré una vez fue que SET ARITHABORT OFF en SSMS hizo que el proceso almacenado se volviera a compilar y/o se usaran diferentes estadísticas. Y de repente, tanto SSMS como ADO.NET informaron aproximadamente el mismo tiempo de ejecución.
Para verificar esto, mire los planes de ejecución para cada ejecución, específicamente la tabla syscacheobjects. Probablemente serán diferentes.
Ejecutar 'sp_recompile' en un procedimiento almacenado específico eliminará el plan de ejecución asociado del caché, lo que le da a SQL Server la oportunidad de crear un plan posiblemente más apropiado en la próxima ejecución del procedimiento.
Finalmente, puede probar el enfoque de "bombardearlo desde la órbita" de limpiar todo el caché del procedimiento y los búferes de memoria usando SSMS:
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
Hacerlo antes de probar su consulta evita el uso de planes de ejecución almacenados en caché y caché de resultados anteriores.
