Beeinflusst Sql JOIN die Leistung?

Question

Ich war aufräumt nur einige SQL, wenn ich auf diese Abfrage kam:

SELECT 
     jm.IMEI , 
     jm.MaxSpeedKM , 
     jm.MaxAccel , 
     jm.MaxDeccel , 
     jm.JourneyMaxLeft , 
     jm.JourneyMaxRight , 
     jm.DistanceKM , 
     jm.IdleTimeSeconds , 
     jm.WebUserJourneyId , 
     jm.lifetime_odo_metres , 
     jm.[Descriptor] 
FROM dbo.Reporting_WebUsers AS wu WITH (NOLOCK) 
     INNER JOIN dbo.Reporting_JourneyMaster90 AS jm WITH (NOLOCK) ON wu.WebUsersId = jm.WebUsersId 
     INNER JOIN dbo.Reporting_Journeys AS j WITH (NOLOCK) ON jm.WebUserJourneyId = j.WebUserJourneyId 
WHERE (wu.isActive = 1) 
     AND (j.JourneyDuration > 2) 
     AND (j.JourneyDuration < 1000) 
     AND (j.JourneyDistance > 0) 

Meine Frage ist es für alle Performance-Unterschied

FROM dbo.Reporting_JourneyMaster90 AS jm 

die Reihenfolge der Verknüpfungen wie für die obige Abfrage macht ich getan habe

würde

und dann trat die anderen 2 Tabellen zu diesem

Answer 1

Nein, der JOIN-Auftrag wird während der Optimierung geändert.

Der einzige Vorbehalt ist die Option FORCE ORDER, die Joins in der exakten Reihenfolge erzwingen, in der Sie sie angegeben haben.

Answer 2

Normalerweise nicht. Ich bin nicht 100% wörtlich auf Sql-Server anwendbar, aber in Postgres behält sich der Abfrageplaner das Recht vor, die inneren Joins nach Belieben neu anzuordnen. Die Ausnahme ist, wenn Sie eine Schwelle erreichen, über die es zu teuer ist, die Reihenfolge zu ändern.

Answer 3

JOIN Reihenfolge spielt keine Rolle, die Abfrage-Engine reorganisiert ihre Reihenfolge basierend auf Statistiken für Indizes und andere Sachen.

Für Test wie folgt vor:

• select zeigen tatsächliche Ausführungsplan und führen erste Abfrage
• Änderung JOIN Ordnung und führen nun die Abfrage erneut
• vergleichen Ausführung

plant sie sollte identisch sein, da die Abfrage-Engine sie nach anderen Faktoren reorganisiert.

Wie auf anderen asnwer kommentiert, könnten Sie OPTION (FORCE ORDER) verwenden, um genau die Reihenfolge zu verwenden, die Sie wünschen, aber vielleicht wäre es nicht der effizienteste.

Als allgemeine Faustregel sollte JOIN order mit der Tabelle der kleinsten Datensätze oben sein, und die meisten Datensätze dauern, da einige DBMS-Engines die Reihenfolge unterscheiden können, wenn der Befehl FORCE ORDER verwendet wurde helfen Sie, die Ergebnisse zu begrenzen.

Answer 4

Falsch. SQL Server 2005 ist definitiv wichtig, da Sie das Dataset vom Anfang der FROM-Klausel aus begrenzen. Wenn Sie mit 2000 Datensätzen anstelle von 2 Millionen beginnen, wird Ihre Abfrage schneller.

Answer 5

Die Join-Reihenfolge im SQL2008R2-Server wirkt sich zweifelsohne auf die Abfrageleistung aus, insbesondere in Abfragen, bei denen eine große Anzahl von Tabellen-Joins mit Where-Klauseln auf mehrere Tabellen angewendet wird.

Obwohl die Join-Reihenfolge in der Optimierung geändert wurde, versucht der Optimierer nicht alle möglichen Join-Aufträge. Es hört auf, wenn es findet, was es für eine praktikable Lösung hält, da der Akt der Optimierung wertvolle Ressourcen verbraucht.

Wir haben gesehen, dass Abfragen, die wie Hunde (1min + Ausführungszeit) ausgeführt wurden, nur durch Ändern der Reihenfolge der Join-Ausdrücke auf eine Subsekunden-Leistung herunterkommen. Bitte beachten Sie jedoch, dass dies Abfragen mit 12 bis 20 Joins und Where-Klauseln zu mehreren Tabellen sind.

Der Trick besteht darin, Ihre Bestellung festzulegen, um dem Abfrageoptimierer zu helfen herauszufinden, was sinnvoll ist. Sie können Force Order verwenden, aber das kann zu starr sein. Stellen Sie sicher, dass Ihre Join-Reihenfolge mit den Tabellen beginnt, in denen die Daten am meisten durch where-Klauseln reduziert werden.

Answer 6

Ich habe ein klares Beispiel für innere Join Auswirkungen auf die Leistung. Es ist eine einfache Verbindung zwischen zwei Tabellen. Einer hatte mehr als 50 Millionen, der andere 2.000. Wenn ich aus der kleineren Tabelle auswähle und der größeren beitrete, dauert es mehr als 5 Minuten.

Wenn ich aus der größeren Tabelle auswähle und der kleineren beitrete dauert es 2 min 30 Sekunden.

Dies ist mit SQL Server 2012.

Für mich unlogisch ist, da ich die größte Datenmenge für die erste Abfrage verwenden.