MySQL Tabelle flotter machen

[Bernhard Geyer]

Zitat:

Zitat von Medium (Beitrag 1145775)

(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. :gruebel:

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

[Medium]

@Bernhard: Keine doofe Idee. Das wird aber eher ein Job für über Nacht :)

Alle Spalten indizieren grad getestet, der Gewinn ist aber leider auch wieder nur sehr marginal. Ich werde mal ein Update des Servers anregen. Schade, ich hatte gehofft da gehörig was falsch gemacht zu haben. Ggf. muss ich dann zum äussersten greifen, und die DB Operationen in einen Thread verlagern, um zumindest das UI etwas geschmeidiger zu machen. Danke euch!

[vagtler]

Ist denn wirklich die Abfrage so langsam oder die Darstellung?

Eine so einfache Abfrage einer Ergebnismenge mit 150k Zeilen dürfte eigentlich innerhalb kürzester Zeit ausgeführt werden.

[Medium]

Angezeigt wird ja immer nur ein Bruchteil (~50 Zeilen) in einem AdvDBGrid, dass imho recht intelligent darstellt. Ich hab das Grid mal abgeklemmt, und es bleibt gefühlt gleich lang, bis die Abfrage zurück. Sowas doofes, das wäre ja noch relativ leicht zu fixen gewesen.

[jobo]

Zitat:

Zitat von Medium (Beitrag 1145766)

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.

[Medium]

Oha, es gibt da einen heftigen Zusammenhang zwischen Größe des Resultsets und Geschwindigkeit. Frage ich alle Daten in einem Zeitraum von 2 Monaten ab (~58.000 Sätze), dauert das reine Ausführen der Query gut 9 Sekunden. Frage ich nach Daten für einen Tag (~950 Sätze), ist das zackig. (Getestet im guten alten MySQL Administrator bzw. Query Browser). Die Zeiten kommen so in etwa auch in meinem Client hin.
Ich vermute dann einfach mal, dass sich da wirklich nicht viel machen lässt. Dann wird auf jeden Fall schon mal das automatische Refresh nach Änderung der Filter rausgeworfen, so dass der Benutzer das manuell auslösen muss. Das ist nämlich das Problem: Während man die Filter einstellt wird einige Male refreshed, und dabei treten natürlich auch unrealistische Bedingungen ein, wie sehr große Zeiträume.

Also habe ich gar kein Problem in der DB, sondern viel mehr im UI. Mit solchen Datenmengen hatte ich bislang auch nicht zu arbeiten - man lernt ja doch nie aus :)

[jobo]

Zitat:

Zitat von Medium (Beitrag 1145808)

> 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.
..
Frage ich nach Daten für einen Tag (~950 Sätze), ist das zackig.
..

So, also die Filterung geht schnell und das (anschließende) Sortieren von 1000 Sätzen ist ein Furz. Das meinte ich mit "würde ich vernachlässigen". Vorausgesetzt natürlich, die Ergebnismenge ist garantiert klein genug.
Im UI machst Du ja auch nichts falsch, Du quälst den Server nur durch unnötig großzügige Benutzerfunktionen.