Выполнение одного и того же запроса от C # VS SSMS дает разное время выполнения

12

У меня есть такая просьба

SELECT 
[EstimateId], 
[CreationUserId], 
[EstimateStatusValueId], 
[LanguageId], 
[LocationId], 
[EstimatorUserId], 
[FilterUnitSystemTypeId], 
[EstimateNumber], 
[RevisionNumber], 
[CreationDate], 
[ModificationDate], 
[ProjectDescription], 
[IsBsdq], 
[ClosingDate], 
[ClosingTime], 
[ClosingUpdatedOn], 
[DeadLineDate], 
[IsReceived], 
[Inclusion], 
[Exclusion], 
[Misc], 
[Note], 
[WorkDeadLines], 
[Comments], 
[Validity], 
[PlansLocation], 
[PlansReceivedFrom], 
[Price]
FROM [Estimate].[Estimates] 
ORDER BY [ClosingDate] ASC, [ClosingTime] ASC

Когда я запускаю этот запрос в SSMS, я получаю время выполнения 953 мс, но когда я запускаю этот запрос из запроса Linq в моем C #, я получаю время выполнения 1813 мс.

В запросе Linq используется «поставщик данных .Net SqlClient», который выдается против EntityFramework (файл EDMX). Это может быть проблемой?

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

Я проверил все планы выполнения обоих запросов, и они используют один и тот же индекс для удовлетворения своих запросов.

Чтобы увидеть план выполнения запроса C #, я использую профилировщик SQL, чтобы перехватить событие Show Plan XML, и сравниваю его с одним из SSMS, и оба они одинаковы.

sql-server-2008 database-tuning Нико
источник
просто маленький вопрос - почему вы выбираете все данные таблицы без каких-либо условий поиска? Вам действительно нужны все данные в приложении без какой-либо фильтрации?
Marian
Да, это функция, которая мне нужна, но эта функция будет использоваться не часто. Я знаю, что не оптимально выдавать большой запрос без предложения where.
Нико
В любом случае меня беспокоит не сам запрос, а разница между временем выполнения. Я показываю вам этот запрос, но все запросы дают схожие результаты. Почему ?
Нико

Ответы:

6

Это последовательно, раз за разом?

Я вижу разницу в процессоре, которая может быть во время компиляции. Есть ли какие-либо настройки LINQ, которые влияют на это?

Редактировать:

  • Захватить планы в Profiler
  • Вы уверены, что SQL в Profiler одинаков ?
ГБН
источник
Да, это последовательно раз за разом. Я не знаю для настроек linq. но я нашел эту ссылку codeproject.com/KB/cs/linqsql2.aspx
Nico
Вы можете увидеть план на картинке выше для обоих запросов. Да, я уверен, что SQL одинаков в профилировщике. Приложения SQL, Profiler, SSMS и C # размещены на моем компьютере для целей разработки.
Нико
Захват фактического плана в XML от Profiler. Не из кеша. У вас разные ответы, но вы показываете другой план = неправильный план, показанный выше, может быть
gbn
3

Вы захотите взглянуть на планы выполнения для двух запросов и увидеть, где они отличаются.

mrdenny
источник
я просто редактирую свой пост ... и уже проверяю, что оба запроса используют один и тот же план.
Нико
1
Я просто добавляю событие, которое вы сказали мне, в профилировщик, и оно совпадает с моим последним запросом, который я публикую в своем вопросе. У меня такие же планы ... любая другая идея ...
Нико
2
Все выглядит правильно. Единственное, что могло бы объяснить это, было бы, если приложение .NET не получает данные достаточно быстро. Время, сообщаемое в SQL Profiler, включает количество времени для передачи данных с сервера на клиент. Так что, если клиент не загрузит все достаточно быстро, время выполнения будет больше.
Мрденный
2
Затем все сводится к тому, что приложение делает с данными, и как оно читает данные из базы данных.
Мрденный
3
В поддержку ответа mrdenny я добавлю, что я тестировал запрос в 3 разных клиентах SQL, и время их отправки было разным, хотя статистика ввода-вывода и выполнение планов были идентичными. Все это было вызвано внутренним отношением клиентов к данным. Я полагаю, что вы можете получить разные результаты по времени, выводя в файл, в сетку в Management Studio или в текстовый вывод. В любом случае, насколько я помню, в документации сказано, что SQL всегда будет быстрее, чем LINQ to SQL, так что это не удивительно :-).
Marian