Tengo un procedimiento almacenado que se ejecuta mucho más rápido desde Sql Server Management Studio (2 segundos) que cuando se ejecuta conSystem.Data.SqlClient.SqlCommand (tiempo de espera después de 2 minutos).

¿Cuál podría ser la razón de ésto

Details: en Sql Server Management Studio, esto se ejecuta en 2 segundos (en la base de datos de producción):

EXEC sp_Stat
    @DepartmentID = NULL

In .NET / C # los siguientes tiempos de espera después de 2 minutos (en la base de datos de producción):

string selectCommand = @"
EXEC sp_Stat
    @DepartmentID = NULL";
string connectionString = "server=***;database=***;user id=***;pwd=***";
using (SqlConnection connection = new SqlConnection(connectionString))
{
    using (SqlCommand command = new SqlCommand(selectCommand, connection))
    {
        connection.Open();
        using (SqlDataReader reader = command.ExecuteReader())
        {
            while (reader.Read())
            {
            }
        }
    }
}

También probé conselectCommand = "sp_Stat", CommandType = StoredProcedure, y unSqlParameter, pero es el mismo resultado.

Y sinEXEC es el mismo resultado también.

En una base de datos de desarrollo casi vacía de datos, ambos casos finalizan en menos de 1 segundo. Entonces, está relacionado con que hay muchos datos en la base de datos, pero parece que solo suceden desde .NET ...

Lo que Marc Gravell escribió sobre diferentesSET valores hace la diferencia en el caso presentado.

SQL Server Profiler mostró que Sql Server Management Studio ejecuta el siguienteSET 's que .NET Sql Client Data Provider no:

SET ROWCOUNT 0 
SET TEXTSIZE 2147483647 
SET NOCOUNT OFF 
SET CONCAT_NULL_YIELDS_NULL ON 
SET ARITHABORT ON 
SET LOCK_TIMEOUT -1 
SET QUERY_GOVERNOR_COST_LIMIT 0 
SET DEADLOCK_PRIORITY NORMAL 
SET TRANSACTION ISOLATION LEVEL READ COMMITTED 
SET ANSI_NULLS ON 
SET ANSI_NULL_DFLT_ON ON 
SET ANSI_PADDING ON 
SET ANSI_WARNINGS ON 
SET CURSOR_CLOSE_ON_COMMIT OFF 
SET IMPLICIT_TRANSACTIONS OFF 
SET QUOTED_IDENTIFIER ON
SET NOEXEC, PARSEONLY, FMTONLY OFF

Cuando incluí estos, la misma consulta tomó la misma cantidad de tiempo en SSMS y .NET. Y el responsableSET es ..

SET ARITHABORT ON

¿Qué he aprendido? Quizás usar un perfilador en lugar de adivinar ...

(La solución al principio parecía estar relacionada con la detección de parámetros. Pero había mezclado algunas cosas ...)