Mysql Speed

Seite 1 von 3 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/mysql_speed_68187/page_1 - zur Vollversion wechseln!

Hey Leute

Wenn ich bei meiner aktuellen Site eine Datenbankabfrage mache, die mehrere ca. 300 Datensätze mit 11 Zellen/Datensatz zurückgibt, dauert diese Abfrage schon recht lange. Man hat einer merkliche Verzögerung von ca. 1 Sekunden, bis die Seite komplett angezeigt wird. (Ausgegeben wird das Ganze dann in einer While Schleife in Form einer Tabelle)

1te Frage: Ist das normal? Oder ist die Datenbank meines Hosters einfach lahm?

2te Frage: Würde es speedmäßig etwas bringen, wenn ich das erhaltene Array z.B. in einer Session speichere und anschließend alles weitere mit diesem array mache (nachträgliches sortieren, darin suchen, usw.)?
Das dumme an der Lösung wäre halt, dass ich das array neuladen muss, sobald etwas an den Datensätzen geändert wurde.

*tia*

Christoph

@Mods: THX for moving

zeig her deine query, zeig her dein tabellen-modell.

300 records downloaden kann natürlich etwas zeit dauern, aber vielleicht verbraucht die abfrage (zb aufgrund fehlender indeces, cpu-fressenden bedingungen) unnötig lange.

Query ist: mysql_query ("SELECT * FROM filme ORDER BY $sortby ASC");

Hmmm ... indices ... hmmm ...

Die Tabelle schaut so aus ...



Hoffe das reicht so ... Die Typen der Zellen müssen noch angepasst werden.

die mysql-text-shell gibt dir zur jeder query eine bearbeitungszeit aus. mach einen test, dann lege für die meisten suchkriterien einen index an, und teste nochmal.

PS: gibst du immer alle 300 auf einmal aus? falls nicht, schau dir die LIMITS-klausel an.

Also es gibt eine Seite, wo er alle auf einmal ausgibt
Hmmm ... Vielleicht mach ich einfach mehrere Seiten draus und lass pro Seite nur 50 oder 100 ausgeben.
Ansonsten gibt er nur bestimmte Datensätze aus, z.B. alle die seit dem letzten Login neu sind.

Das dumme ist ja, dass bei einer SELECT * Abfrage die Indices nichts helfen. Oder irre ich da?

beim sortieren sollten sie helfen, oder irre ich mich ?

ausserdem gilt auch zu bedenken, daß der aufbau von tabellen mit sehr vielen zeilen oder spalten auch beim browser zeit kostet.

okidoki.
Werd mir das morgen mal genauer anschauen und durchtesten.

du hast da ein paar sachen in die datenbank eingebaut:
1. du speicherst 300 mal zb. das genre hinein, da sich das aber immer wiederholt wäre es intelligenter, nur einen integer-index in das feld zu schreiben und diesen dann später zuordnen (das gleiche mit sprache, quali - besitzer unter umständen und codec)

2. du hast mehrere felder die nicht null sein dürfen, aber keinen default-wert haben

3. der einzige schlüssel den du hast is ein integer, statt eines bigint und wahrscheinlich noch signed

4. das datum is ein bigint... ähm, wofür gibt es das date, datetime, timestamp-formate?

wenn du zumindest punkt 1 "behebst" wird deine datenbank um ca 1/3 kleiner... und die memorynutzung sinkt auch gewaltig -> mehr speed

Zitat von watchout

du hast da ein paar sachen in die datenbank eingebaut:
1. du speicherst 300 mal zb. das genre hinein, da sich das aber immer wiederholt wäre es intelligenter, nur einen integer-index in das feld zu schreiben und diesen dann später zuordnen (das gleiche mit sprache, quali - besitzer unter umständen und codec)

2. du hast mehrere felder die nicht null sein dürfen, aber keinen default-wert haben

3. der einzige schlüssel den du hast is ein integer, statt eines bigint und wahrscheinlich noch signed

4. das datum is ein bigint... ähm, wofür gibt es das date, datetime, timestamp-formate?

wenn du zumindest punkt 1 "behebst" wird deine datenbank um ca 1/3 kleiner... und die memorynutzung sinkt auch gewaltig -> mehr speed

Zitat von watchout

du hast da ein paar sachen in die datenbank eingebaut:
1. du speicherst 300 mal zb. das genre hinein, da sich das aber immer wiederholt wäre es intelligenter, nur einen integer-index in das feld zu schreiben und diesen dann später zuordnen (das gleiche mit sprache, quali - besitzer unter umständen und codec)

Sodala hab jetzt mal die indices getestet.
Leider ohne Erfolg

Ein Query nach SELECT * FROM filme ORDER BY genre, titel ASC dauert 0,42secs

egal ob ich einen index genre,titel hab oder nicht.
Vorausgesetzt ich hab beim adden des Index nichts falsche gemacht.
Verwendet hab ich folgeneden Query: ALTER TABLE `filme` ADD INDEX (genre,titel)

Zitat von rettich

was ist schneller: ein "select *" wo das genre als varchar drin steht oder ein integer-wert mit einem "join" auf die genre-tabelle

ich nehme, es ist nicht der join. die vom db-server übertragene datenmenge bleibt aber gleich.

(wobei ich natürlich zustimme: mit einer genre-table ist das db modell sauberer, egal, wie viel zeit das kostet )

Zitat von Maehmann

Jetzt stell sich die Frage ob das wirklich sinnvoll ist,

wir wollen ihn nicht gleich beim ersten programm mit er-modellen und 3. Normalform (3NF) zuschütten, mittelfristig sollte maehmann sich das aber unbedingt anschauen.
wer ein gutes leicht verständliches tutorial dazu hat, möge es hier posten.
dieses ist zwar für access, erklärt den aufbau aber mit recht einfachen worten: http://www.uni-koeln.de/rrzk/kurse/...n/access/er.pdf
PS: das sortieren nach zwei varchar(200) feldern ist natürlich wirklich sehr cpu lastig ;(

ob die lösung mit detail- bzw lookup-tables wirklich langsamer ist, müssate man ausprobieren: zwar ist das joinen zweier tabellen komplexer, dafür muß in der zweiten tabelle eine kleinere datenmenge sortiert werden, und dann können bereits die IDs auf die haupttabelle angewand werden, und man muß nur noch die elemente sortieren, welche die selbe detail-id besitzen. die besten sortier-algorithmen haben etwa einen aufwand von n*log(n). kann man diese sortierte menge in zwei einzeln zu sortierende menge teilen, dann reduziert sich der gesamt-aufwand; 2*(n/2*log(n/2)) ist weniger als n*log(n). das verhältnis wird umso besser, je mehr genres es gibt.
ausserdem ist der stringvergleich vieler identer strings langsamer als der vergleich unterschiedlicher strings. das liegt daran, daß identität erst beim vergleich des letzen zeichens festgestellt wird, während größer/kleiner mit dem ersten nicht identen zeichen feststeht.welcher effekt (komplexität gegen optimierung) bei 300 datensätzen stärker ins gewicht fällt, traue ich mir hier nicht zu sagen.

Ich kenn das tutorial http://ffm.junetz.de/members/reeg/DSP/

Ist glaub ich auch ganz brauchbar. Wär mir das Kapitel mit den Normalformen gleich mal genau anschauen

overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025