2011-10-19 18 views
5

Ho un paio di mesi di esperienza lavorativa con Entity Framework e principalmente sto scrivendo una tonnellata di query linq di recupero dati contro di esso. Vengo da uno sfondo pesante SQL e sto cercando di ottimizzare alcuni dei sql per prestazioni e leggibilità se sto cercando di risolvere i problemi di prestazioni.Entity Framework Query Optimization

Sto notando alcuni dei SQL generato fa le cose come questo per un tableA con colonne {col1, col2, col3}

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

La mia domanda è, come faccio a impedire che fare queste tabelle derivate inutili , e invece basta fare

select col1 from tableA 

dove è necessario? Non riesco a capire perché a volte fa questa e altre volte non lo fa ...

+0

Sono interessato ad ascoltare i pensieri di altre persone; ma penso che questo sia solo uno degli svantaggi dell'uso di EF (così come di altri ORM?). Si perde molto controllo sull'attuale SQL generato e l'SQL generato è spesso piuttosto scadente. – CodingGorilla

+0

possibile duplicato di [Migliorare la query generata dal framework entità] (http://stackoverflow.com/questions/7418675/improve-query-generated-from-entity-framework) –

risposta

4

Hai confrontato i piani di esecuzione della query effettiva della query generata rispetto a come la ottimizzeresti? Potresti essere sorpreso dai risultati, lo so che lo ero. E ho acquisito un profondo rispetto per gli sviluppatori del team di SQL server che sembrano fare un ottimo lavoro nel rendere quella che sembra una query sub-ottimale eseguire lo stesso.

Sarei interessato a sentire se la tua esperienza è diversa dalla mia; Ho smesso di cercare i modi per cambiare le query generate perché per ogni query che ho provato a guardare non c'era alcuna differenza reale nelle prestazioni.

EDIT: mia ultima affermazione non è del tutto vero, ci sono sicuramente N + 1 situazioni che si devono guardare fuori per, e le eventuali operazioni batch (aggiornamenti, eliminazioni, e inserti di più record allo stesso tempo) non saranno nemmeno vicini nelle prestazioni per scrivere una query a mano a causa della natura del lavoro con i singoli record. Ma le estensioni estranee vengono essenzialmente rimosse dal Query Optimizer di SQL Server.

+0

Ciao Joel, in generale hai ragione, ma io ho un paio di domande davvero brutte che sono lunghe circa 300 righe che fanno questa "inutile tabella derivata" business più volte. Prendendo questa query e semplicemente sostituendo le tabelle derivate con la loro successiva selezione diretta dalla controparte della tabella prende una query enorme come quella da 7 secondi a sub 1 secondi .... quindi sono d'accordo con te per la maggior parte, ma cercando di capire come posso ottimizzare al meglio il mio linq in modo da non incorrere in questo problema. – Zom

+0

@ Isamu: in genere se è possibile semplificare la query LINQ, anche l'SQL diventa più semplice. Ci sono molte tecniche per farlo, ma senza alcun codice da guardare in primo luogo, è difficile dare un consiglio specifico. Il guadagno di prestazioni> 7x che stai segnalando è il risultato diretto della rimozione delle colonne non necessarie dal codice generato da EF o stai facendo trasformazioni più complesse? – StriplingWarrior

+1

Suppongo che tu abbia tenuto conto del caching delle query quando hai verificato la differenza di rendimento ... Esiste un post sul blog del team EF (http://blogs.msdn.com/b/adonet/archive/2011/07/ 25/generated-sql-improvements-for-tpt-queries.aspx) aperto per il feedback su problemi specifici relativi al miglioramento delle prestazioni per SQL generato. Questo post specifico parla dei miglioramenti apportati quando si ha a che fare con una gerarchia di ereditarietà di classe table-per-type nella versione più recente. –