Почему какой-то запрос sql намного медленнее при использовании с SqlCommand?

У меня есть хранимая процедура, которая выполняется намного быстрее из Sql Server Management Studio (2 секунды), чем при запуске с System.Data.SqlClient.SqlCommand (время истекает через 2 минуты).

Что может быть причиной этого?

Подробнее: В Sql Server Management Studio выполняется через 2 секунды (в производственной базе данных):

EXEC sp_Stat
    @DepartmentID = NULL

В .NET/С# следующие тайм-ауты через 2 минуты (в производственной базе данных):

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())
            {
            }
        }
    }
}

Я также пробовал с selectCommand = "sp_Stat", CommandType = StoredProcedure и a SqlParameter, но это тот же результат.

И без EXEC это тот же результат.

В почти базе данных, свободной от данных, оба случая заканчиваются менее чем за 1 секунду. Таким образом, это связано с тем, что в базе данных много данных, но, похоже, это происходит только из .NET...

То, что написал Марк Гравелл о разных значениях SET, делает разницу в представленном случае.

Профилировщик SQL Server показал, что Sql Server Management Studio запускает следующее SET, которое поставщик данных .NET Sql не выполняет:

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

Когда я включил их, один и тот же запрос занял одинаковое количество времени в SSMS и .NET. И ответственный SET - это...

SET ARITHABORT ON

Что я узнал? Возможно, использовать профайлер вместо угадывания...

(Решение сначала казалось связанным с параметризацией, но я кое-что перепутал...)

Ответы

CREATE PROCEDURE usp_MyProcedure WITH RECOMPILE...

exec sp_msforeachtable "dbcc dbreindex('?')"