Wykonanie tego samego żądania z C # VS SSMS daje inny czas wykonania

Mam taką prośbę

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

Kiedy uruchamiam to zapytanie w SSMS, otrzymuję czas wykonania 953ms, ale kiedy uruchamiam to zapytanie z zapytania Linq w moim C #, otrzymuję czas wykonania 1813ms.

Kwerenda Linq używa „.Net SqlClient Data Provider” i jest wydawana przeciwko EntityFramework (plik EDMX). Czy to może być problem?

Czy ktoś wie, dlaczego mam dużą różnicę między czasami wykonania tych żądań, które są takie same, ale są wykonywane z innego kontekstu na tej samej bazie danych?

Sprawdziłem wszystkie plany wykonania obu żądań i używają tego samego indeksu, aby spełnić odpowiednie zapytanie.

Aby zobaczyć plan wykonania żądania C #, używam profilera SQL do przechwytywania zdarzenia Show Plan XML i porównuję go do SSMS i oba są takie same.

sql-server-2008 database-tuning

— Nico
źródło

tylko małe pytanie - dlaczego wybierasz wszystkie dane tabeli bez żadnego warunku wyszukiwania? Czy naprawdę potrzebujesz wszystkich danych w aplikacji bez filtrowania?

— Marian

Tak, jest to funkcja, której potrzebuję, ale ta funkcja nie będzie często używana. Wiem, że nie jest optymalne wydawanie dużych zapytań bez klauzuli where.

— Nico,

W każdym razie moim zmartwieniem nie jest sama prośba, ale różnica między czasami wykonania. Pokazuję ci to zapytanie, ale wszystkie zapytania dają podobne wyniki. Dlaczego ?

— Nico,

Odpowiedzi:

Czy to jest spójne za każdym razem?

Widzę różnicę procesora, która może być czasem kompilacji. Czy wpływają na to jakieś ustawienia LINQ?

Edytować:

Uchwyć plany w programie Profiler
Czy jesteś pewien, że SQL jest taki sam w programie Profiler ?

— gbn
źródło

Tak, to spójny raz za razem. Nie wiem dla ustawień linq. ale znalazłem ten link codeproject.com/KB/cs/linqsql2.aspx

— Nico

Możesz zobaczyć plan na zdjęciu powyżej dla obu zapytań. Tak, jestem pewien, że SQL jest taki sam w programie profilującym. Aplikacje SQL, Profiler, SSMS i C # są hostowane na moim komputerze w celach programistycznych.

— Nico,

Przechwyć aktualny plan w formacie XML z Profiler. Nie z pamięci podręcznej. Masz różne odpowiedzi, ale pokazujesz inny plan = może zły plan pokazany powyżej może

— gbn

Myślę, że problem polega na użyciu pliku EDMX do generowania zapytań z aplikacji C #.

Znalazłem linki, które wyjaśniają sprawę.

Projekt kodowy

Stackoverflow-1

Stackoverflow-2

— Nico
źródło

Będziesz chciał spojrzeć na plany wykonania dla dwóch zapytań i zobaczyć, gdzie się różnią.

— mrdenny
źródło

po prostu edytuję mój post ... i już sprawdzam, czy oba zapytania korzystają z tego samego planu.

— Nico

Dodałem po prostu wydarzenie, które mi powiedziałeś, do profilera i jest to to samo, co moja ostatnia prośba, którą opublikowałem w swoim pytaniu. Mam te same plany ... każdy inny pomysł ...

— Nico

Wszystko wygląda poprawnie. Jedyną rzeczą, która mogłaby to wyjaśnić, byłoby to, że aplikacja .NET nie odbiera danych wystarczająco szybko. Czas zgłaszany w SQL Profiler obejmuje czas na przesłanie danych z serwera do klienta. Jeśli więc klient nie pobierze wszystkiego wystarczająco szybko, zgłaszany czas działania będzie dłuższy.

— mrdenny

Następnie sprowadza się do tego, co aplikacja robi z danymi i jak odczytuje dane z bazy danych.

— mrdenny,

Na poparcie odpowiedzi mrdenny'ego dodam, że przetestowałem zapytanie w 3 różnych klientach SQL, a ich zgłaszane czasy były różne, chociaż statystyki IO i wykonanie planów były identyczne. Wszystko to było spowodowane wewnętrznym sposobem traktowania danych przez klientów. Uważam, że można uzyskać różne wyniki czasowe, wysyłając dane do pliku, do siatki w Management Studio lub do tekstu. W każdym razie, z tego co pamiętam, dokumentacja mówi, że SQL zawsze będzie szybszy niż LINQ na SQL, więc nie jest to niespodzianką :-).

— Marian