|
Thread!!!
|
a.XL
Usernummer # 10634
|
 verfasst
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
|
philipp
Usernummer # 687
|
verfasst
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.
|
philipp
Usernummer # 687
|
verfasst
Schau mal hier rein:
![[hand]](graemlins/hand.gif) 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]](smile.gif)
|
a.XL
Usernummer # 10634
|
verfasst
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]](wink.gif)
optimiert mysql wohl auch?
|
philipp
Usernummer # 687
|
verfasst
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.
|
a.XL
Usernummer # 10634
|
verfasst
kostet aber zeit.
als pragmatiker ist es sicher wichtiger, sql zu beherrschen. wenn die datenbank das dann sowieso optimiert, umso besser.
|
philipp
Usernummer # 687
|
verfasst
Das ist 'ne schöne Feierabendlektüre Will dich aber zu nix zwingen!
|
harryp
Usernummer # 5896
|
verfasst
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.
|