nicht angemeldet
yo,
Hy Ilja,
tuning ist wohl mit das schwierigste, weil man sich schon gut mit dem jeweiligen dbms auskennen muss. du befindest dich also in der königsdiziplin und dort gilt der grundsatz, immer probieren über studieren.
Diesen Grundsatz kenne ich, nur oft verheddert man sich denn auch, und am Ende ist es schlimmer als vorher. ;)
zum einen würde es auch interessant sein zu wissen, wie genau du den index erstellt hast. zum anderen wie viele datensätze du als resultset zurück bekommst und wie die kardinalität der daten aussieht, sprich sind viele werte in einer spalte gleich oder unterscheiden sie sich stark. zum anderen ist deine abfrage auch insofern kritisch, da du nicht auf exakte werte mit = prüfst, sondern wertebereiche. es gibt also im vorfeld viel zu klären, bevor man vermuten kann, was deine abfrage schneller machen würde. in der praxis ptüfen muss man das dann eh immer.
Wie gesagt anfangs war es nen Multi Index allen Feldern, die in der Where Bedingung stehen, dort ist mir mitlerweile aber im Explain aufgefallen, dass in rows, die Summe aller Datensätze stand, so habe ich es auf tabelle_campaign_status verringert. Die einzigen Felder, die noch ne höhere Kardinalität als 3 erreichen können, sind tabelle_prio (1-6) und tabelle_status (0-10) und tabelle_touch (0-60). UNd mit tabelle_prio scheint er arge Probleme zu haben, sobald ich dieses Feld in den Index mit einbaue, fliegen mir die Ausführungszeiten um die Ohren... :(
Zu den Werte Bereichen, da könnte ich sicher an der Stelle: tabelle_prio und tabelle_status drehen, nur denn weiß ich nicht, ob die Abfragen wieder zuviel werden, da das Skript, welches die Query nutzt, schon häufig auf die DB zu greift. Weil wenn ich erst nach dem Status 1, denn 2 und so schaue, kann es schon passieren, dass das zu viel wird.
Falls noch Infos gewünscht, kann ich die gerne liefern. :)
Ilja