L'esecuzione della stessa richiesta da C # VS SSMS fornisce tempi di esecuzione diversi

Ho una richiesta come questa

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

Quando eseguo questa query in SSMS ottengo un tempo di esecuzione di 953 ms, ma quando eseguo questa query da una query Linq nel mio C # ottengo un tempo di esecuzione di 1813 ms.

La query Linq utilizza il ".Net SqlClient Data Provider" e viene emessa su EntityFramework (file EDMX). Questo può essere un problema?

Qualcuno sa perché ho una grande differenza tra i tempi di esecuzione di quelle richieste che sono uguali ma eseguite da un contesto diverso rispetto allo stesso database?

Ho verificato tutti i piani di esecuzione di entrambe le richieste e utilizzano lo stesso indice per soddisfare le rispettive query.

Per vedere il piano di esecuzione della richiesta C # uso il profiler SQL per intercettare l'evento Show Plan XML e lo confronto con quello di SSMS ed entrambi sono uguali.

sql-server-2008 database-tuning

— nico
fonte

solo una piccola domanda: perché stai selezionando tutti i dati della tabella senza alcuna condizione di ricerca? Hai davvero bisogno di tutti i dati nell'applicazione senza alcun filtro?

— Marian,

Sì, questa è una funzione di cui ho bisogno, ma questa funzione non verrà utilizzata spesso. So che non è ottimale emettere una query di grandi dimensioni senza clausola where.

— Nico,

Comunque la mia preoccupazione non è la richiesta stessa ma la differenza tra tempi di esecuzione. Vi mostro questa query ma tutte le query danno risultati simili. Perché ?

— Nico,

Risposte:

È coerente, di volta in volta?

Vedo una differenza di CPU che potrebbe essere il tempo di compilazione. Ci sono delle impostazioni LINQ che influiscono su questo?

Modificare:

Cattura i piani in Profiler
Sei sicuro che SQL sia lo stesso in Profiler ?

— GBN
fonte

Sì, è coerente di volta in volta. Non lo so per le impostazioni di Linq. ma ho trovato questo link codeproject.com/KB/cs/linqsql2.aspx

— Nico

Puoi vedere il piano nella foto sopra per entrambe le query. Sì, sono sicuro che SQL è lo stesso nel profiler. App SQL, Profiler, SSMS e C # sono tutte ospitate sul mio computer a scopo di sviluppo.

— Nico,

Cattura il piano reale in XML da Profiler. Non dalla cache. Hai risposte diverse ma mostri un piano diverso = piano sbagliato mostrato sopra forse

— gbn

Penso che il problema risieda nel file EDMX utilizzato per generare query dall'app C #.

Ho trovato quei collegamenti che spiegano il caso.

Progetto di codice

StackOverflow-1

StackOverflow-2

— nico
fonte

Ti consigliamo di esaminare i piani di esecuzione per le due query e vedere dove sono diverse.

— mrdenny
fonte

ho appena modificato il mio post ... e ho già verificato che entrambe le query utilizzano lo stesso piano.

— Nico,

Aggiungo semplicemente l'evento che mi hai detto nel profiler ed è lo stesso della mia ultima richiesta che inserisco nella mia domanda. Ho avuto gli stessi piani ... qualsiasi altra idea ...

— Nico,

Sembra tutto corretto. L'unica cosa che potrebbe spiegarlo sarebbe se l'applicazione .NET non riceve i dati abbastanza rapidamente. Il tempo riportato in SQL Profiler include la quantità di tempo per trasferire i dati dal server al client. Quindi, se il client non scarica tutto abbastanza rapidamente, il tempo di esecuzione riportato sarà più lungo.

— mrdenny,

Quindi si tratta di cosa sta facendo l'applicazione con i dati e come sta leggendo i dati dal database.

— mrdenny,

A supporto della risposta di mrdenny aggiungerei che ho testato una query in 3 diversi client SQL e i loro tempi riportati erano tutti diversi sebbene le statistiche IO e l'esecuzione dei piani fossero identiche. Tutto è stato causato dal modo interno di come i client hanno trattato i dati. Credo che sia possibile ottenere risultati temporali diversi inviando a un file, alla griglia in Management Studio o all'output di testo. Comunque, da quello che ricordo, la documentazione diceva che SQL sarà sempre più veloce di LINQ a SQL, quindi questa non è una sorpresa :-).

— Marian