Виконання того ж запиту від C # VS SSMS дає різний час виконання

У мене є такий запит

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 Provider Data Provider" і видається проти EntityFramework (файл EDMX). Чи це може бути проблемою?

Хтось знає, чому у мене велика різниця між часом виконання тих запитів, які однакові, але виконуються з іншого контексту проти однієї бази даних?

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

Щоб побачити план виконання запиту C #, я використовую SQL-провідник, щоб захопити подію Show Plan XML і порівняти його з одним із SSMS, і обидва вони однакові.

sql-server-2008 database-tuning

— Ніко
джерело

лише невелике запитання - чому ви вибираєте всі дані таблиці без будь-яких умов пошуку? Вам справді потрібні всі дані в додатку без фільтрування?

— Маріан

Так, це функція, яка мені потрібна, але ця функція буде використовуватися не часто. Я знаю, що не оптимально задавати великий запит без де застереження.

— Ніко-

У всякому разі, мене турбує не сам запит, а різниця між часом виконання. Я показую вам цей запит, але всі запити дають подібні результати. Чому?

— Ніко-

Відповіді:

Це послідовно, час від часу?

Я бачу різницю процесора, яка могла б скласти час компіляції. Чи є параметри LINQ, які впливають на це?

Редагувати:

Захопіть плани в Profiler
Ви впевнені, SQL , те ж саме в Profiler ?

— гбн
джерело

Так, це послідовно час від часу. Я не знаю для налаштувань linq. але я знайшов це посилання codeproject.com/KB/cs/linqsql2.aspx

— Ніко,

Ви можете побачити план на малюнку вище для обох запитів. Так, я впевнений, що SQL однаковий у профілі. Програми SQL, Profiler, SSMS та C # розміщуються на моєму комп'ютері з метою розробки.

— Ніко-

Захопіть фактичний план у XML від Profiler. Не з кешу. У вас є різні відповіді, але ви показуєте інший план = неправильний план, показаний вище, можливо

— gbn

Я думаю, що проблема полягає у використанні файлів EDMX для генерації запитів із програми C #.

Я знайшов ті посилання, які пояснюють випадок.

Код проекту

Stackoverflow-1

Stackoverflow-2

— Ніко
джерело

Ви хочете подивитися плани виконання двох запитів і побачити, де вони відрізняються.

— мрденний
джерело

я просто редагую свою публікацію ... і я вже підтверджую, що обидва запити використовують один і той же план.

— Ніко-

Я просто додаю подію, яку ви мені повідомили, у профілер, і це те саме, що і мій останній запит, який я публікую у своєму запитанні. У мене були ті ж плани .. будь-яка інша ідея ...

— Ніко,

Все виглядає правильно. Єдине, що може пояснити це, було б, якщо програма .NET не отримає дані досить швидко. Час, повідомлений у SQL Profiler, включає кількість часу для передачі даних із сервера клієнту. Тож якщо клієнт не завантажить все досить швидко, повідомлений час запуску буде довшим.

— мрденний

Потім зводиться до того, що програма працює з даними, і як вона читає дані з бази даних.

— mrdenny

На підтримку відповіді mrdenny я додам, що я протестував запит у трьох різних клієнтах SQL, і їх звітний час був різним, хоча статистика IO та плани виконання були однаковими. Все це було викликано внутрішнім способом того, як клієнти ставилися до даних. Я вважаю, що ви можете отримати різні результати часу, вивівши у файл, в сітку в студії управління або на текстовий вихід. У будь-якому випадку, як я пам'ятаю, документація сказала, що SQL завжди буде швидше, ніж LINQ в SQL, так що це не сюрприз :-).

— Маріан