MySQL Tabelle flotter machen

[Medium]

@generic: Wie komme ich an die Pläne, und wie kann ich die Nutzung meiner Indizes dann im Zweifelsfall gewährleisten? (Ich bräuchte ja vor allem erst mal sinnvolle Indizes )

Die Version ist so eine Sache. Der PC incl. MySQL ist vom Kunden beigestellt, das wird eher nicht so einfach möglich sein.
Speicher:
Der PC hat 2GB
MySQL
Key Buffer 2MB
Sort buffer 212kB
InnoDB
Buffer pool size 11MB
Additional mem Pool size 2MB

Bevor ich aber am Server selbst rumdrehe (bzw. das veranlassen muss), glaube ich, dass da Potenzial in Tabelle und Abfrage stecken muss - die sind nämlich damals noch recht naiv entstanden, als erste Gehversuche nach Umstellung von Paradox auf MySQL als Standard-DB hier im Betrieb. Zumindest hoffe ich, dass der aktuelle Zustand hochgradig unoptimal ist

[DeddyH]

EXPLAIN sollte eine Reihe von Informationen liefern.

[Medium]

Zitat von DeddyH:

EXPLAIN sollte eine Reihe von Informationen liefern.

Code:

EXPLAIN SELECT * FROM log
WHERE (printerdate BETWEEN '01-01-2011 00:00:00' AND '01-02-2011 00:00:00')
ORDER BY printerdate, packagenr

Liefert:
select_type = SIMPLE
table = log
type = ALL
possible_keys = null
key = null
key_len = null
ref = null
rows = 167389 (das sind alle)
Extra = Using where; Using filesort

Leider sagt mir das nicht viel, ausser dass mir "filesort" irgendwie doof klingt.

[DeddyH]

Dann setz doch einmal einen Index auf printerdate und wiederhole das Ganze noch einmal. Zumindest die Testabfrage sollte dann schon etwas schneller Ergebnisse liefern, sofern nicht wieder null unter possible_keys gemeldet wird.

[Medium]

Der Key wird, laut explain, dann durchaus verwendet, aber wird es subjektiv entweder kaum oder garnicht schneller, wenn ich die Abfrage abschicke
(Ich mach das via PC-Anywhere auf dem Server beim Kunden direkt, so dass Netzwerklaufzeiten keine Rolle spielen dürften.)
Da war meine Hoffnung auf ein "Wah! Stell einfach mal das und jenes um, und es fluppst - sowas weiss man doch!" leider zu optimistisch hm?

[Bernhard Geyer]

Zitat von Medium:

(Ich mach das via PC-Anywhere auf dem Server beim Kunden direkt, so dass Netzwerklaufzeiten keine Rolle spielen dürften.)

Wieso ziehst du dir die DB nicht? Dann kannst du in Ruhe rumspielen um auch mal MySQL-parameter zu verändern.

[Valle]

Du musst doch (für's erste) einfach nur je einen Index auf jede Spalte setzen, die in WHERE oder ORDER vorkommt.

Anschließend würde ich noch ein aktuelles MySQL 5 nehmen und schauen, dass man wirklich nur die Datensätze holt die man braucht.

Wenn der Server dann einigermaßen Ressourcen besitzt, ist da nicht mehr viel zu machen, bei so einer simplen Struktur.

Liebe Grüße,
Valentin

[jobo]

Zitat von Medium:

Code:

EXPLAIN SELECT * FROM log
WHERE (printerdate BETWEEN '01-01-2011 00:00:00' AND '01-02-2011 00:00:00')
ORDER BY printerdate, packagenr

Ich muss mal ahnungslos fragen:
Wird das in mySQL tatsächlich sauber umgesetzt?
M.E. steht dort:
Nimm das Datumsfeld printerdate und schaue, wo es zwischen den Text(!)werten [von] und [bis] liegt.

Die Engine wird ja geezwungen, entweder den eigentlich Spaltenwert zu Text zu konvertieren oder die Operanden zu date. Kenne keine mySLQ explain ausgaben, aber die zeigen ja scheinbar, dass kein Index verwendet wird.

Vorschlag:
Explizite Konvertierung des Datums im Select und ggF. mit dem between spielen, also zerlegen in (für den Optimizer) "einfachere" Kriterien.

zu
"3. Die Sortierung auf einem Ergebnisset <1000 erst mal vernachlässigen"
Wenn dank Filterung das Ergebnisset so klein ist, ist die Sortierung belanglos. Zumindest bei halbwegs aktueller Hardware. Damit wären Indizes auf den Sortierspalten überflüssig.

zu
"Angezeigt wird ja immer nur ein Bruchteil (~50 Zeilen) in einem AdvDBGri"
Das Anzeigen hat nichts damit zu tun, was der SServer alles durchorgeln muss. Wenn Du es sortiert haben willst, kann er ja schlecht hergehen und nur die ersten 50 Datensätze sortieren.
50 Datensätze holen, spart nur den Großteil des Transportes zum Client, nicht die Sortierung von 150k Sätzen.

[Medium]

> Wird das in mySQL tatsächlich sauber umgesetzt?
Wird es, das ist allerdings ein "Mock" für's EXPLAIN. Im Programm sind alle Werte über Parameter gesetzt, in diesem Fall .AsDateTime.
MySQL erkennt Strings in einem gültigen Datumsformat, und konvertiert diese wenn für ein Datumstyp-Feld eingesetzt automatisch.

> Wenn dank Filterung das Ergebnisset so klein ist, ist die Sortierung belanglos. Zumindest bei halbwegs aktueller Hardware. Damit wären Indizes auf den Sortierspalten überflüssig.
Wie kann ich MySQL denn verständlich machen, erst den WHERE Teil auszuwerten, dann ORDER BY? Tut es das nicht ohnehin schon? Das wäre doch sonst sträflich für ein DBMS.

> Das Anzeigen hat nichts damit zu tun, was der SServer alles durchorgeln muss. Wenn Du es sortiert haben willst, kann er ja schlecht hergehen und nur die ersten 50 Datensätze sortieren.
vagtler meinte sicherlich die Zeit, die so manche Komponente zum Zeichnen verbrät, wenn man sie reichlich füttert. Listboxen und Treeviews sind da ja z.B. recht anfällig. Das war es dann ja aber auch nicht.

[vagtler]

Ja, ich meinte schon die Differenz zwischen der Dauer der reinen Abfrage und halt der Zeit bis zur Darstellung des gewünschten Ergebnis (also inkl. Transferleistung).

Ich würde das Statement mal in einem entsprechenden Tool (im Zweifelsfall die MySQL Workbench oder auch SQLyog oder was auch immer) ausführen - da sehe ich dann mal wirklich genau, wie lange das Statement als solches braucht.