nicht angemeldet
Hi Cheatah,
CREATE INDEX indexname ON tabellenname (zahlenfeld, ip (15), page (250),
nochwasanderes)
Welchen Tabellentyp verwendest Du?
Hat dessen Auswahl (und der dabei implizit angezogene Treiber) einen Einfluß auf das Phänomen?
"ip" war als TINYTEXT
Was hältst Du davon, die IP zu konvertieren und als unsigned 32 bit integer zu speichern?
Das müßte den Indexzugriff beschleunigen und zudem Platz sparen (vor allem im Index - in der Tabelle ist der Unterschied eher vernachlässigbar).
Nachdem der Index jedoch angelegt war, brachte ein Billig-Select der Art
SELECT page, count(*)
FROM tabelle
WHERE zahlenfeld=? AND ip=?
GROUP BY page
kein Ergebnis mehr
Grübelgrübel ...
Ein EXPLAIN auf das Statement verriet mir, dass genau dieser Index verwendet
werden sollte.
... das wäre meine nächste Frage gewesen ...
Auch das Entfernen der Spalte "nochwasanderes" im Index änderte dies
nicht.
Nun ja, ich sollte noch erwähnen, dass der Inhalt der Spalte "ip" meist
auf "127.0.0.1" lautete und damit die Länge 15 nicht erreichte.
Wenn ich "meist" wörtlich nehmen soll, dann ist der Index so nicht sehr projektiv. (Aber wahrscheinlich wird er das bei richtigen Produktionsdaten sein.)
In jedem Fall ist Deine Anordnung der beiden Felder im Index m. E. so richtig herum ...
Oder ist das ein (mittlerweile gefixter) Bug?
Es könnte sein, daß "3.23" dafür eine zu ungenaue Angabe ist.
(Ich verwende 3.23.38, aktuell ist wohl 3.23.47.)
Viele Grüße
Michael
(der sich gerade mit etwas vage Ähnlichem herumschlägt: Ein CREATE FULLTEXT INDEX auf etwa 100 MB Textdaten erzeugt nach knapp 2 Stunden den anscheinend richtigen Indexbaum [dessen Größe mir bekannt ist], aber statt diesen und die temporäre Version der Tabelle dann auf den endgültigen Dateinamen umzubenennen, beschließt der mySQL-daemon, eine Endlosschleife mit 100% CPU-Auslastung lustiger zu finden ...)