MYSQL Index bei ORDER BY Division?

[mgutt]

Hi,

ich habe eine Abfrage die per ORDER BY (spalte1 / spalte2) sortiert wird.

Was für ein Index macht hier Sinn?

Gruß

[Falk Prüfer]

Hallo,

für dieses ORDER BY wird MySQL keinen Index verwenden können, da berechnete Indizes meines Wissens nicht unterstützt werden.

Gruß Falk

[dimitri]

Einer auf spalte1 und spalte2 oder auch gar keiner. Das läßt sich so nicht benatworten.

Dim

[mgutt]

Hallo,

für dieses ORDER BY wird MySQL keinen Index verwenden können, da berechnete Indizes meines Wissens nicht unterstützt werden.

Gruß Falk

Demnach sollte ich das Ergebnis in eine eigene Spalte bringen. Hatte ich befürchtet. Wollte es aber eigentlich vermeiden, weil das eigentlich es nur eine Abfrage betrifft, die aber dafür auf der Startseite ausgegeben wird.

[mgutt]

Einer auf spalte1 und spalte2 oder auch gar keiner. Das läßt sich so nicht benatworten.

Dim

Auf beide oder meinst Du jetzt einzeln? Und wenn auf beide, welche Spalte zuerst ^^

Ich probier mal durch...

[dimitri]

Auf beide oder meinst Du jetzt einzeln? Und wenn auf beide, welche Spalte zuerst

Ach das war eine Division? Dass hab ich gar nicht richtig gesehen. Dann macht natürlich nur ein funktionsbasierter Index Sinn aber da der unter mysql nicht unterstützt ist wird es damit leider nichts werden.

Dim

[mgutt]

Ach das war eine Division? Dass hab ich gar nicht richtig gesehen. Dann macht natürlich nur ein funktionsbasierter Index Sinn aber da der unter mysql nicht unterstützt ist wird es damit leider nichts werden.

Dim

Ja steht doch im Titel Mönsch ^^

Ok, dann bleibt nur der Weg das Ergebnis ebenfalls zu hinterlegen.

Trotzdem danke.

[dibo33]

Du kannst auch ein Index auf spalte1 / spalte2 setzen ohne ein zusätzliches Feld anzulegen, die Frage ist halt die Relation Abfrage/Änderung der Tabelle.

[Falk Prüfer]

Hallo,

Du kannst auch ein Index auf spalte1 / spalte2 setzen ohne ein zusätzliches Feld anzulegen, die Frage ist halt die Relation Abfrage/Änderung der Tabelle.

also die mir bekannte Syntax (bis einschl. V5.5) zum Anlegen eines Index läßt nur die Angabe einer Spaltenliste aber keine Ausdrücke zu.

CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name
    [index_type]
    ON tbl_name (index_col_name,...)
    [index_option] ...

index_col_name:
    col_name [(length)] [ASC | DESC]

und "spalte1 / spalte2" ist ein Ausdruck und keine Spaltenliste.

Gruß Falk

[mgutt]

Also ich habe mal alles durchprobiert (einzelne und mehrspaltige). Ein Index auf spalte1 hat die beste Wirkung. Ist aber nicht zufriedenstellend.

Vorher: ca. 0.7 Sekunden
Nachher: ca. 0.3 Sekunden

Allerdings habe ich zusätzlich dagegen gesteuert, in dem ich die Abfrage von live auf 90 Tage Cache umgestellt habe.

Mir ist aber wieder mal aufgefallen, dass MySQL die falschen Indexe wählt. Wenn das so weiter geht, besteht bald jede Abfrage bei mir aus FORCE INDEX().

[Falk Prüfer]

Hallo,

Also ich habe mal alles durchprobiert (einzelne und mehrspaltige). Ein Index auf spalte1 hat die beste Wirkung.

mag sein dass der Index die Abfrage insgesamt beschleunigt in Bezug auf mögliche Join- und Where-Bedingungen. Für die Sortierung spielt er aber sicher keine Rolle.

Gruß Falk

[mgutt]

Im WHERE-Teil findet sich nur host=x, forum=x und active=1. Und in einer 2. Version Grenze ich zusätzlich noch den Zeitraum ein mit time>=x. Aber views oder replies kommt nur bei ORDER BY vor.

Abfrage:

SELECT *
FROM threads 
WHERE host = 1
AND forum NOT IN(0)
AND active = 1
ORDER BY (views / (replies +1)) DESC
LIMIT 10

Getestet habe ich Indexe auf host_views, host_replies, host_threads, views_replies, views und replies.
Es gibt dabei im Ergebnis folgende Unterschiede:

host hat viele threads (>100.000):
- Index views 0.3 sec
- alle anderen Indexe 0.6 bis 0.9 sec

host hat wenige threads (<1.000):
- Index views 0.1 sec
- host_views und host_threads 0.0001 sec
- alle anderen auch noch schnell bis 0.3 sec

Auch wenn bei hosts mit wenigen threads die Abfrage mit views langsamer ist, habe ich mich für views als Index entschieden, weil die stabiler bezogen auf die Zukunft erscheint.

Die letzte Alternative das Ergebnis in eine extra Spalte zu packen, lasse ich erstmal sein, da die Abfrage jetzt eh durch den Cache so gut wie gar nicht mehr ins Gewicht fällt. Erst wenn wir bei 1.000.000 threads sind, muss ich mir denke ich wieder Gedanken machen

Das der Index Wirkung zeigt liegt denke ich daran, dass views als Basis für die Berechnung die Anzahl der Zeilen maginal reduziert und damit der Zugriff beschleunigt wird.