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

12

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:

6

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
3

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
1
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
2
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
2
Następnie sprowadza się do tego, co aplikacja robi z danymi i jak odczytuje dane z bazy danych.
mrdenny,
3
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