5-секундный SP, достигающий 30-секундного таймаута через LINQ-to-SQL

Question

У меня есть SP, который выполняется через 5 секунд через SSMS

Когда тот же SP выполняется через надстройку LINQ-to-SQL Excel, он истекает через 30 секунд (более простые запросы для этого же SP занимают много времени, но возвращают результаты)

Затем я изменил SP, чтобы он переназначил все входные параметры на новые локальные параметры внутри SP. Это заставило SP работать в SSMS за 36 секунд (поэтому есть причина, по которой SSMS так быстро начинался)

Итак, я предполагаю, что SQL-сервер не использует анализ параметров для моих запросов LINQ-to-SQL?

Итак, мой вопрос: есть ли способ сделать SP настолько быстрым в LINQ-to-SQL, как в SSMS (с анализом параметров)

Answer 1

SQL Server оптимизирует хранимые процедуры одинаково, независимо от того, вызываете ли вы их из SSMS или из LINQ.Но он использует план кеширования.План сохраняется для последующего повторного использования с теми же настройками входа в систему + ansi.Первые переданные значения могут определить, как выглядит план.Если другой логин / настройки начинаются с разных значений, это может привести к другому плану кэширования.Это одно из объяснений различий в производительности между LINQ и SSMS.

Чтобы сбросить все кэшированные планы, используйте:

DBCC FREEPROCCACHE

, чтобы оптимизировать SP точно для тех значений, которые вы вызываете, вы можете использовать with recompile:

create procedure dbo.MySP with recompile as ...

Это вызывает компиляцию процедуры для каждого вызова.Это сведет на нет параметризацию.

(Ваша ситуация довольно необычна. В SQL Server есть опция принудительная параметризация , но нет возможности предотвратить это.)