Можете ли вы заставить Linq2SQL НЕ использовать sp_executesql?

Question

Итак, я пишу запрос Linq, и для его выполнения требуется 16 секунд. Решите посмотреть, каков план запроса, поэтому я перенес его из Linq в SQL Profiler, и выполнение запроса занимает всего 2 секунды. Вздох

Потратив большую часть дня на изучение и, наконец, приступив к использованию SQL Server Profiler, я вижу, что Linq2SQL использует sp_executesql для выполнения запроса. Я понимаю, что это должно улучшить производительность, потому что он с большей вероятностью повторно использует план выполнения ... но, похоже, он выбрал ужасный план выполнения.

Более странной особенностью является то, что она становится медленной, только если я присоединяюсь к определенной таблице, и я понятия не имею, почему эта конкретная таблица вызывает проблему.

РЕДАКТИРОВАТЬ Просто чтобы прояснить актуальную проблему здесь:

На самом деле это зависит от разных запросов. Один, по сути,

SELECT col1, col2, ... FROM table1, table2 WHERE table1.val IN (1234, 2343, 2435)

Другой

EXEC sp_executesql 'SELECT col1, col2, ... FROM table1, table2 WHERE table1.val IN (@p1, @p2, @p3)', 
N'@p0 int,@p1 int,@p2 int,@p3 int',
@p0=1234, @p1=2343, @p3=2435

Answer 1

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

Медленно в приложении, быстро в SSMS?
Понимание загадок производительности

Это будетдать вам глубокое понимание того, почему вы получаете разницу в производительности, как ее диагностировать и последовательно воспроизводить, и, наконец, как ее решить.

Answer 2

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

Различные планы выполнения могут привести к значительным различиям в производительности, коэффициент 100 не является чем-то необычным. В качестве первого шага проверьте, отличаются ли планы выполнения. Событие профилировщика performance -> showplan xml регистрирует план.

Если план отличается, одной из возможных причин могут быть параметры сеанса, например ansi nulls :

SET ANSI_NULLS 

Другой возможностью является другой вход в систему (план содержит информацию о безопасности, поэтому каждый контекст безопасности имеет свой собственный набор кэшированных планов выполнения.)

Самый простой способ очистить кэш плана - перезапустить службу SQL Server. Также имеется расширенная команда для очистки всего кэша плана запросов :

DBCC FREEPROCCACHE

P.S. Если у вас есть хранимая процедура, которая выполняется по-разному в зависимости от значения параметров, стоит проверить сниффинг параметров . Но так как вы копируете ту же самую процедуру из профилировщика, я предполагаю, что параметры идентичны как для медленных, так и для быстрых вызовов.

Answer 3

Чтобы ответить на ваш вопрос ....

НЕТ, вы не можете ...