[SQL] PK niet gebruikt in join als tabel niet gespecificeerd

[Tjolk]

Ik heb de volgende (versimpelde) query:

SQL:

SELECT 
    [...]
FROM
    data_order_rule
JOIN data_order USING(order_id)
JOIN data_user USING(user_id)
JOIN data_address ON address_id = address_id_shipping
WHERE [...]

Die query duurt vrij lang, dus hop, een EXPLAIN ervoor gezet. Daarbij zie ik dat de primary key address_id (in de tabel data_address) niet gebruikt wordt.

Pas ik de query aan:

SQL:

SELECT 
    [...]
FROM
    data_order_rule
JOIN data_order USING(order_id)
JOIN data_user USING(user_id)
JOIN data_address ON data_address.address_id = data_order.address_id_shipping
WHERE [...]

Dan wordt mijn query ± 90% sneller en wordt de PK wél gebruikt.

Blijkbaar zit het verschil er dus in dat ik de tabel benoem in mijn ON clause. Nu is mijn probleem an sich dus opgelost, maar ik vraag me hoe dit verschil te verklaren is gezien de werking van MySQL. Immers: data_address is de enige tabel met een kolom address_id en data_order is de enige tabel met een kolom address_id_shipping. (logisch, anders zou de query ook falen).

Wie verlicht mij?

[dik_voormekaar]

Ik vermoed dat het te maken heeft met het feit dat de tabel data_order zelf ook een gejoinde tabel is. Wellicht blijkt dit uit de twee explain's.
Zou je die kunnen posten?

[Tjolk]

Verrek. Ik doe nu de EXPLAIN voor de eerste query, en krijg nu wel netjes de PK terug als gebruikte key.
Sterker nog: de EXPLAINS zijn gewoon gelijk?

[gekkie]

was je 2e query niet gewoon sneller door een opgewarmde cache oid ?

[Woy]

Ik denk dat er bijvoobeeld iets mis was met de table statistics waardoor de Query engine dacht dat het zonder PK te gebruiken sneller zou zijn.

De query's zijn met of zonder table-prefix namelijk na verwerken exact gelijk ( Bij een ambigu column definition zou je een fout krijgen immers )

[Tjolk]

[b][message=43178105,noline]De query's zijn met of zonder table-prefix namelijk na verwerken exact gelijk ( Bij een ambigu column definition zou je een fout krijgen immers )

Dat was mijn idee ook al inderdaad. Goed, conclusie: niets aan het handje.
Toch bedankt voor het meedenken

[ge-flopt]

Mogelijk een oud (lees niet goed) execution plan in het geheugen. En doordat je éénmalig aangeeft hoe de query goed moet lopen dat hij het execution plan aanpast.