Wenn dieselbe Anforderung von C # VS SSMS ausgeführt wird, ist die Ausführungszeit unterschiedlich


12

Ich habe eine Anfrage wie diese

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

Wenn ich diese Abfrage in SSMS ausführe, erhalte ich eine Ausführungszeit von 953 ms, aber wenn ich diese Abfrage von einer Linq-Abfrage in meinem C # ausführe, erhalte ich eine Ausführungszeit von 1813 ms.

Die Linq-Abfrage verwendet den ".Net SqlClient Data Provider" und wird gegen EntityFramework (EDMX-Datei) ausgegeben. Kann das ein Problem sein?

Weiß jemand, warum ich einen großen Unterschied zwischen den Ausführungszeiten der Anforderungen habe, die gleich sind, aber aus verschiedenen Kontexten für dieselbe Datenbank ausgeführt werden?

Ich habe alle Ausführungspläne beider Anforderungen überprüft und sie verwenden denselben Index, um ihre jeweilige Abfrage zu erfüllen.

Um den Ausführungsplan der C # -Anforderung anzuzeigen, verwende ich den SQL-Profiler, um das Show Plan XML-Ereignis abzufangen, und vergleiche es mit dem von SSMS, und beide sind gleich.


nur eine kleine frage - warum wählen sie alle tabellendaten ohne suchbedingung aus? Benötigen Sie wirklich alle Daten in der Anwendung ohne Filterung?
Marian

Ja, dies ist eine Funktion, die ich brauche, aber diese Funktion wird nicht oft verwendet. Ich weiß, dass es nicht optimal ist, eine große Abfrage ohne where-Klausel auszuführen.
Nico

Jedenfalls geht es mir nicht um die Anfrage selbst, sondern um den Unterschied zwischen den Ausführungszeiten. Ich zeige Ihnen diese Abfrage, aber alle Abfragen liefern ähnliche Ergebnisse. Warum ?
Nico

Antworten:


6

Ist das immer wieder konsistent?

Ich sehe einen CPU-Unterschied, der Kompilierungszeit sein könnte. Gibt es irgendwelche LINQ-Einstellungen, die dies beeinflussen?

Bearbeiten:

  • Erfassen Sie die Pläne in Profiler
  • Sind Sie sicher, dass SQL in Profiler identisch ist ?

Ja, es ist immer wieder konsistent. Ich weiß es nicht für Linq-Einstellungen. aber ich fand diesen Link codeproject.com/KB/cs/linqsql2.aspx
Nico

Sie können den Plan im Bild oben für beide Abfragen sehen. Ja, ich bin sicher, dass der SQL-Code im Profiler identisch ist. SQL, Profiler, SSMS und C # -App werden zu Entwicklungszwecken auf meinem Computer gehostet.
Nico

Erfassen Sie den aktuellen Plan in XML von Profiler. Nicht aus dem Cache. Sie haben unterschiedliche Antworten, aber Sie zeigen einen anderen Plan = falscher Plan, der oben vielleicht gezeigt wird
gbn


3

Sie sollten sich die Ausführungspläne für die beiden Abfragen ansehen und feststellen, wo sie sich unterscheiden.


Ich bearbeite gerade meinen Beitrag ... und ich verifiziere bereits, dass beide Abfragen denselben Plan verwenden.
Nico

1
Ich füge nur das Ereignis, das du mir erzählt hast, in den Profiler ein und es ist das gleiche wie meine letzte Anfrage, die ich in meiner Frage poste. Ich habe die gleichen Pläne ... jede andere Idee ...
Nico

2
Alles sieht richtig aus. Das Einzige, was dies erklären könnte, wäre, wenn die .NET-Anwendung die Daten nicht schnell genug erhält. Die in SQL Profiler gemeldete Zeit enthält die Zeit, die zum Übertragen der Daten vom Server zum Client benötigt wird. Wenn der Client also nicht alles schnell genug herunterlädt, ist die gemeldete Laufzeit länger.
Mrdenny

2
Dann kommt es darauf an, was die Anwendung mit den Daten macht und wie sie die Daten aus der Datenbank liest.
Mrdenny

3
Zur Unterstützung von mrdennys Antwort möchte ich hinzufügen, dass ich eine Abfrage in 3 verschiedenen SQL-Clients getestet habe und deren gemeldete Zeiten alle unterschiedlich waren, obwohl die E / A-Statistiken und die Ausführung der Pläne identisch waren. Dies lag alles an der internen Art und Weise, wie die Kunden mit den Daten umgingen. Ich glaube, dass Sie unterschiedliche Zeitergebnisse erzielen können, wenn Sie in einer Datei, im Raster in Management Studio oder in der Textausgabe ausgeben. Soweit ich mich erinnere, heißt es in der Dokumentation, dass SQL immer schneller sein wird als LINQ to SQL. Das ist also keine Überraschung :-).
Marian
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.