technoforum.de: [sql] cross join vs. inner join

This is topic [sql] cross join vs. inner join in forum Produktions- & DJ-Technik, Hard- & Software at technoforum.de.

Um den Thread anzusehen, klicke auf diesen Link:
https://forum.technoforum.de/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=6;t=007084

Geschrieben von: a.XL (Usernummer # 10634) an :

hallo,

fallst hier gerade ein datenbank-experte unterwegs sein sollte. intuitiv habe ich das gefühl, dass die abfrage

code:

SELECT * FROM t1, t2 WHERE t1.id=t2.xyz_id AND t2.x=7

langsamer sein müßte als

code:

SELECT * FROM t1 INNER JOIN t2 ON (t2.x=7 AND t1.id=t2.xyz_id)

wobei hier also t2.xyz_id ein fremdschlüssel ist, der mit t1.id verknüpft ist.

die frage hängt natürlich von der datenbank und der implementierung der abfragaroutinen ab. aber rein der idee nach wird bei der ersten abfrage erst das kreuzprodukt erzeugt und dann aus gemäß diesem where-klausel ausgewählt. bei der zweiten abfrage wird jedoch direkt nur eine auswahl des kreuzprodukts erzeugt. durch die verschiebung eines teils der where-klausel der gesamtabfrage in die join-bedingung (on) müßte man so doch eine menge performance sparen können. oder???

hat jemand eine begründete meinung dazu?

gruß
axel

Geschrieben von: philipp (Usernummer # 687) an :

Ich habe meinen Datenbankprof damals das selbe gefragt, denn ich kannte vorher nur die erste Variante (bzw. hatte mich mit Joins noch nicht beschäftigt). Im Prinzip hast du Recht, alle Datenbanken optimieren aber ihre Operatorbäume zumindest so gut dass so einfache Abfragen wie deine gleich schnell sein werden, weil sie den gleichen optimierten Operatorbaum ergeben. Wie auch bei Compilern lohnt es sich bei DB-Anfragen kaum, von Hand zu optimieren.

Geschrieben von: philipp (Usernummer # 687) an :

Schau mal hier rein:

[hand]

http://www.informatik.uni-bonn.de/III/lehre/vorlesungen/Informationssysteme/WS02/folien.html

Dort die Kapitel zur Anfragebearbeitung, da ist das ganze recht anschaulich erklärt [Smile]

Geschrieben von: a.XL (Usernummer # 10634) an :

danke, das habe ich mir schon fast gedacht. sehr interessanter link. mittlerweile ärgere ich mich, dass ich in meinem informatik-nebenfach-studium keine datenbankvorlesung besucht habe, sondern mich mit formaler logik beschäftigt habe... irgendwie fand ich datenbanken nie so aufregend: zweidimensionale matrizen. gähn. [Wink]

optimiert mysql wohl auch?

Geschrieben von: philipp (Usernummer # 687) an :

mysql optimiert mit ziemlicher Sicherheit. Ich hab die Vorlesung eigentlich auch "nur" besucht um meine schon aus der Praxis vorhandenen Kenntnisse zu vervollständigen, hat sich schon gelohnt. Arbeite doch einfach mal die PDFs durch, ist nicht besonders schwer.

Geschrieben von: a.XL (Usernummer # 10634) an :

kostet aber zeit. [Wink]

als pragmatiker ist es sicher wichtiger, sql zu beherrschen. wenn die datenbank das dann sowieso optimiert, umso besser.

Geschrieben von: philipp (Usernummer # 687) an :

Das ist 'ne schöne Feierabendlektüre [Wink]

Will dich aber zu nix zwingen!

Geschrieben von: harryp (Usernummer # 5896) an :

Zitat:
Ursprünglich geschrieben von: a.XL:
kostet aber zeit.

als pragmatiker ist es sicher wichtiger, sql zu beherrschen. wenn die datenbank das dann sowieso optimiert, umso besser.

Manchmal muß man den Optimizer allerdings überreden, einen anderen Weg zu wählen und ihn ein bißchen "überreden".
Zumindest ist das bei DB2 für Z/OS so.
Mit dem Explain - Befehl kannst man hier die SQL-Abfrage analysieren.
Keine Ahnung, ob das bei MySQL geht.

@phillip
Danke für den Link. Der ist klasse.