2013-10-25 3 views
1

У меня странные несоответствия в скорости запросов с помощью функций linq to sql. У меня есть функция, которую я вызываю из приложения MVC. Это всегда очень медленно, в порядке 7 секунд. Когда я вызываю ту же функцию из студии управления SQL, она иногда медленная, а иногда и быстрая (доля секунды). Я не уверен, когда он становится медленным, и когда он становится быстрым точно, но я нашел один цикл (за исключением того, что приложение MVC всегда было медленным), что дает согласованные результаты.Непоследовательная скорость запросов между LINQ и (иногда) SQL

  • Запрос выполняется в приложении. Это медленно.
  • Я пробую запрос точно так же, как LINQ выполняет его. Это находится в форме sp_execute N' select [some] [select] [clauses] from functionname(@p0)', 'declare @p0 decimal(9,0)', @p0=123456789. Это также медленно, при первом запуске и в последовательных прогонах.
  • Я попробовал запрос "unwrapped" в форме select [some] [select] [clauses] from functionname(123456789). Это все еще медленно, также на последовательных прогонах.
  • Я переопределяю функцию с помощью функции alter [...].
  • Выполнение исходного запроса sp_execute по-прежнему медленное, также на censecutive.
  • Эксплуатация развернутой функции выполняется быстро. Действительно быстро.
  • Выполнение первоначального запроса sp_execute также очень быстро. Также с различными параметрами @ p0.
  • запрос выполняется в приложении. мы снова становимся медленными.

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

+0

являются все возможные поля проиндексированы ? выполняете ли вы работу по восстановлению индекса и статистике в ночное время? – m4ngl3r

+1

Если на последовательных прогонах он медленный, это, вероятно, не из-за составления и кэширования планов экзекуции. –

+0

как насчет индексов? – m4ngl3r

ответ

1

Это звучит как прослушивание параметров:

https://www.simple-talk.com/sql/t-sql-programming/parameter-sniffing/ http://blogs.technet.com/b/mdegre/archive/2012/03/19/what-is-parameter-sniffing.aspx

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

1

Вопрос можно объяснить вопрос о parameter sniffing и, также, различные execution settings между вами MVC приложений и управления SQL студии. Разница может быть драматичной.

Дополнительная информация в соответствии с настройками исполнения могут быть найдены here

Среди этого, есть несколько советов, в статье http://www.sommarskog.se/query-plan-mysteries.html

И, конечно, для проверки правильности, необходимо очистить обналичены самолеты: DBCC FREEPROCCACHE; DBCC DROPCLEANBUFFERS

0

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

Чтобы увидеть точное время, затраченное на запрос, вам нужно очистить кэш перед выполнением запроса и что может быть сделано

DBCC FREEPROCCACHE

DBCC DROPCLEANBUFFERS

+0

Как насчет еще медленных последовательных прогонов? – Martijn

Смежные вопросы