Привет!
Теряюсь даже, как описать.

В общем, есть C# код, который, через SqlClient -овские SqlConnection и SqlCommand вызывает, соответственно, ConnectAsync() и ExecuteReaderAsync() .
Результатов может прийти до нескольких десятков, поэтому после каждого ResultSet-а вызывается reader.NextResultAsync() .
Для каждого ResultSet-а строки данных перебираются в цикле while (await reader.ReadAsync()) {...} .

И получаем жуткие тормоза. Чтобы просто перебрать записи занимает где-то в 10 раз дольше, чем тот же вызов процедуры, но в SSMS (SQL Server Management Studio).
Причем даже в таком варианте, где только перебор:



Что мы только не пробовали:
через уже открытое соединение слать сначала T-SQL SET NOCOUNT ON;

добавлять в ConnectionString такой ключ: applicationintent=readonly

играться с SqlConnection.PacketSize

использовать command.ExecuteReaderAsync( CommandBehavior.SequentialAccess )

читать синхронно (вместо while (await reader.ReadAsync()) {...} использовать while (reader.Read()) {...} )

даже так: var table = new DataTable(); table.Load(reader);

Ничего не помогло! Всё таже разница на порядок с SSMS или OSQL.EXE.
Наши JAVA коллеги ржут - переделайте все на JAVA. Блин, но SSMS на том же .NET-е написан, почему такая разница?!

TaPaKYuri Abele,

для начала определите, что же медленно забирает или отрабатывает процедура.
Я не понял вопроса. На всякий случай (см. выше) - на том же PC, тот же запрос и с того же сервера, но в SSMS всё работает на порядок быстрее

Ситуация прояснилась.
Оказалось, что дело совсем не .NET-ном куске.

У этой SP, среди прочего, на входе optional параметр @LastSyncDateTime DATE = NULL
Далее в коде:

SET @LastSyncDateTime = ISNULL(@LastSyncDateTime, '1980-01-01');

Ну и два десятка таблиц, фильтрующихся, по этой дате (все переделать на фильтр по LoadID не предлагать - уже занимаются)

Так вот, если вызывать процедуру и явно передать ей дату, даже такую же, как выше, то всё летает.
Если же параметр не указан или ему явно NULL передали, то всё дико тормозит.

Т.е. похоже, что query optimizator выбирает разные планы выполнения в зависимости от значения параметра на входе, а не того значения, которое, потом, в запросе к таблице применится!
Добавить к заголовку процедуры WITH RECOMPILE никаких изменений не породило.

Наш workarround - еще в backend-е смотрим, что там со значением и подменяем пустое на 1980-01-01:

Корректное решение - не трогать .NET code, а убрать WITH RECOMPILE - нет в нем смысла в нашем случае и добавить где надо:
OPTION (RECOMPILE, USE HINT ('DISABLE_PARAMETER_SNIFFING'))

(чтобы все в одном флаконе, так сказать)

Дело в том, что MSSQL query optimizator, действительно, выбирает план на основе исходного значения параметра процедуры, а мы его переписывали. Поэтому см. предыдущий постинг.