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

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

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

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

EXEC sp_Stat
    @DepartmentID = NULL

В .NET / C # следующее время ожидания истекает через 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 и SqlParameter, но результат тот же.

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

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

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

SQL Server Profiler показал, что 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

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

(Сначала казалось, что решение связано с обнюхиванием параметров. Но я кое-что перепутал ...)