Kann ich diese MySQL-Anfrage optimieren?

[globe]

n'abend,

"rel_content_category1 rel1"  rausnehme (aus der FROM-Klausel), dann sehen die Zahlen bei ROWS gleich viel vernuenftiger aus!
Es scheint also ein Problem zu sein, Tabellen zu nennen, sie dann aber nicht zu verwenden.

wo liegt der sinn eine tabelle (oder in deinem fall ein zwischenergebnis) mit einer weiteren tabelle zu joinen, wenn diese gar nicht gebraucht wird? die SQL Optimzier sind keine götter und erkennen sowas nicht immer.. also unnötigen kram rauslassen...

Stellt sich mir die Frage, wie ich das in der eigentlichen Abfrage realisieren kann? Dort wird ja mittels 'OR' jeweils eine der beiden rel-Tabellen nicht verwendet - und ich glaube, daran liegt es. Kann ich das irgendwie einbauen, ohne die Abfrage zu aendern?

Bedingungen die leichter abzuarbeiten sind, willst du an erster stelle haben!

SELECT DISTINCT c.*
FROM contentTable c, rel_content_category1 rel1, rel_content_category2 rel2
WHERE
(
 rel1.catID IN ('ki', 'fm', 'nr')
 AND
 c.id = rel1.contentID
)

OR
(
 rel2.catID = '6'
 AND
 c.id = rel2.contentID
)

auf diese art und weise sollten zuerst die zwischenergbnisse massiv reduziert werden und erst danach gejoined... dass das den ultimativen schub bringt bezweifle ich allerdings, wenn die indexe nicht benutzt werden...

statt der ORs hab ich das auf nen IN (..) umgeschrieben... IN () verarbeitet MySQL offenbar schneller, als mehrere ORs - ORs sind allgemein böhse und sind zu vermeiden, wo es geht... die kosten mehr zeit als ANDs. der gute demorgan hat da mal regeln für aufgestellt, wie man aus nem OR ein AND machen kann... die frage ist hier nur, ob das mit den beiden NOT-comparisons wirklich schneller läuft...

Hinweis: du kannst auch compund indexe benutzen (index (catID,contentID) )
bei rel1 könnte das dazu führen, dass er nen indexonly scan macht... du kannst mysql auch dazu "zwingen" gewisse indexe zu benutzen... wenn du aber nicht genau weisst was du da machst, solltes du lieber auf die magie des optimziers hoffen ;)

P.S.: falls ich hier irgendwas falsch oder unzureichend schildere möge man mich bitte verbessern... das buch über MySQL Query Optimziation ist schon wieder ziemlich lange her... :/

weiterhin schönen abend...