2011-10-19 25 views
5

Mam kilkumiesięczne doświadczenie w pracy z Entity Framework i głównie pisanie wielu zapytań linq o pobieranie danych. Pochodzę z ciężkiego tła sql i próbuję zoptymalizować niektóre sql dla wydajności i czytelności, jeśli próbuję debugowania problemów z wydajnością.Entity Framework Query Optimization

ja widząc niektóre z wygenerowanym SQL robi takie rzeczy dla TABLEA z kolumnami {col1, col2, Col3}

select 
    Extent1.col1 
from 
(
    select col1, col2, col3 from tableA 
) AS Extent1 

Moje pytanie brzmi, jak mogę uniemożliwić robienie tych bezużytecznych tabele pochodzące , a zamiast tego wystarczy, że jest on potrzebny w razie potrzeby? Nie mogę się domyślić, dlaczego czasami to robi, a czasami nie ...

+0

Jestem zainteresowany słuchaniem myśli innych ludzi; ale myślę, że jest to tylko jeden z wad stosowania EF (jak również innych ORM?). Tracisz dużo kontroli nad faktycznym generowanym SQL, a wygenerowany SQL jest często dość zły. – CodingGorilla

+0

możliwy duplikat [Popraw zapytanie wygenerowane z struktury encji] (http://stackoverflow.com/questions/7418675/improve-query-generated-from-entity-framework) –

Odpowiedz

4

Czy porównałeś rzeczywiste plany wykonania kwerendy z generowanym zapytaniem, w zależności od tego, jak je zoptymalizować? Możesz być zaskoczony wynikami, wiem, że byłem. Zyskałem głęboki szacunek dla twórców z zespołu serwera SQL, którzy wydają się wykonywać doskonałą robotę przy tworzeniu czegoś, co wygląda tak, jak nieoptymalne zapytanie.

Chciałbym usłyszeć, jeśli twoje doświadczenie różni się od mojego; Przestałem szukać sposobów na zmianę generowanych zapytań, ponieważ dla każdego zapytania, które próbowałem sprawdzić, nie było żadnej różnicy w wydajności.

EDIT: Moje ostatnie stwierdzenie nie jest do końca prawda, na pewno są n + 1 sytuacje, które trzeba zwrócić uwagę, a wszelkie operacje wsadowe (aktualizacje, usuwa i wstawki z wielu rekordów jednocześnie czas) nie będą nawet w stanie zbliżyć się do napisania zapytania ręcznie z powodu natury pracy z poszczególnymi zapisami. Ale obcy zakres zostaje zasadniczo usunięty przez optymalizator zapytań SQL Server.

+0

Cześć Joel, generalnie masz rację, ale mam kilka prawdziwych, nieprzyjemnych zapytań o długości około 300 linii, które wielokrotnie wykonują te "nieprzydatne tabele pochodne". Biorąc to zapytanie i po prostu zastępując wyprowadzone tabele kolejnymi bezpośrednimi wyborami z tabeli, bierzesz takie zapytanie od 7 sekund do 1 sekundy ... więc zgadzam się z tobą w większości, ale próbuję wymyślić jak mogę zoptymalizować mój linq, aby nie napotkać tego problemu. – Zom

+0

@Isamu: Ogólnie rzecz biorąc, jeśli możesz uczynić zapytanie LINQ prostszym, SQL staje się prostszy. Jest na to wiele technik, ale bez żadnego kodu na pierwszy rzut oka trudno jest udzielić konkretnej porady. Czy> 7-krotny wzrost wydajności, który raportujesz jako bezpośredni wynik usunięcia niepotrzebnych kolumn z kodu generowanego przez EF, czy też robisz bardziej złożone transformacje? – StriplingWarrior

+1

Zakładam, że zaksięgowano buforowanie zapytań po przetestowaniu różnicy wydajności ... Na blogu zespołu EF znajduje się blog (http://blogs.msdn.com/b/adonet/archive/2011/07/ 25/generated-sql-improvements-for-tpt-queries.aspx), który jest otwarty na opinie na temat konkretnych problemów związanych z poprawą wydajności generowanego SQL. Ten konkretny post omawia ulepszenia, jakie wprowadzili, gdy mamy do czynienia z hierarchią dziedziczenia klas typu tabela w klasie w najnowszej wersji. –