Beschleunigung innerer Joins zwischen einer großen Tabelle und einer kleinen Tabelle

Question

Das mag eine dumme Frage sein, aber es könnte Licht in die Funktionsweise von Joins bringen.

Nehmen wir an, ich habe eine große Tabelle L und eine kleine Tabelle S (100K Zeilen im Vergleich zu 100 Zeilen).

Gäbe es zwischen den beiden folgenden Optionen ?:

OPTION 1:     OPTION 2: 
---------     --------- 
SELECT *     SELECT * 
FROM L INNER JOIN S  FROM S INNER JOIN L 
ON L.id = S.id;   ON L.id = S.id; 

Beachten Sie, dass der einzige Unterschied ist die Reihenfolge, in der die Tabellen verbunden sind, einen Unterschied in Bezug auf die Geschwindigkeit sein.

Ich weiß, dass die Leistung zwischen verschiedenen SQL-Sprachen variieren kann. Wenn ja, wie würde MySQL mit Access vergleichen?

Answer 1

Nein, die Reihenfolge spielt keine Rolle.

Fast alle RDBMS (wie MS Access, MySQL, SQL Server, ORACLE usw.) verwenden einen kostenbasierten Optimierer basierend auf Spaltenstatistiken. In den meisten Situationen wählt der Optimierer einen korrekten Plan. In dem von Ihnen angegebenen Beispiel spielt die Reihenfolge keine Rolle (sofern die Statistiken aktuell sind).

Um welche Abfrage-Strategie zu entscheiden, verwendet die Jet-Engine zu verwenden Optimierer Statistiken. Die folgenden Faktoren sind einige der Faktoren, die diese Statistiken basieren auf:

• Die Anzahl der Datensätze in einer Tabelle
• Die Anzahl der Datenseiten in einer Tabelle
• Die Lage des Tisches
• Ob Indizes vorhanden sind
• Wie einzigartig die Indizes

Hinweis: Sie können Jet-Datenbank-Engine-Optimierungsschemas nicht anzeigen, und Sie können nicht angeben, wie eine Abfrage optimiert wird. Sie können jedoch den Database Documenter verwenden, um zu bestimmen, ob Indizes vorhanden sind und wie eindeutig ein Index ist.

Auf der Grundlage dieser Statistik, die Optimizer wählt dann die besten interne Abfrage-Strategie für mit einer bestimmten Abfrage handelt. Die Statistiken werden aktualisiert, sobald eine Abfrage kompiliert wird. Eine Abfrage wird zum Kompilieren als gekennzeichnet, wenn Sie Änderungen an der Abfrage (oder zugrunde liegenden Tabellen) speichern und wenn die Datenbank komprimiert wird. Wenn eine Abfrage zum Kompilieren markiert ist, tritt das Kompilieren von und das Aktualisieren der Statistik das nächste Mal auf, wenn die Abfrage ausgeführt wird. Compiling dauert in der Regel von einem Sekunde bis vier Sekunden.

Wenn Sie eine erhebliche Anzahl von Datensätze zur Datenbank hinzufügen, müssen Sie geöffnet und dann Anfragen an speichern neu kompilieren, die Abfragen. Beispiel: Wenn Sie entwerfen und dann eine Abfrage mit mithilfe einer kleinen Gruppe von Beispieldaten testen, müssen Sie die Abfrage erneut kompilieren, nachdem zusätzliche Datensätze zur -Datenbank hinzugefügt wurden. Wenn Sie dies tun, möchten Sie sicherstellen, dass optimale Abfrage Leistung erreicht wird, wenn Ihre Anwendung in Verwendung ist.

Ref.

von Interesse sein könnten: ACC: How to Optimize Queries in Microsoft Access 2.0, Microsoft Access 95, and Microsoft Access 97

Tony Toews des Microsoft Access Performance FAQ ist lesenswert.

Answer 2

Ich weiß, Oracle ist nicht auf Ihrer Liste, aber ich denke, dass die meisten modernen Datenbanken sich so verhalten werden.

Im folgenden Ausführungsplan sehen Sie, dass zwischen den beiden Aussagen kein Unterschied besteht.

Es ist ein Vollzugriff auf jede der beiden Tabellen (kein Index in meinem Fall), und dann ein HASH JOIN. Da Sie alles aus beiden Tabellen haben wollen, müssen beide Tabellen gelesen und verknüpft werden, die Reihenfolge hat keine Auswirkungen.

--------------------------------------------------------------------------- 
| Id | Operation   | Name | Rows | Bytes | Cost (%CPU)| Time  | 
--------------------------------------------------------------------------- 
| 0 | SELECT STATEMENT |  | 100 | 700 | 42 (12)| 00:00:01 | 
|* 1 | HASH JOIN   |  | 100 | 700 | 42 (12)| 00:00:01 | 
| 2 | TABLE ACCESS FULL| S | 100 | 300 |  2 (0)| 00:00:01 | 
| 3 | TABLE ACCESS FULL| L | 100K| 390K| 38 (8)| 00:00:01 | 
---------------------------------------------------------------------------