Mysql Speed

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.

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.

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.

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)

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 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 )

Das ist eine gute Frage
Vorallem würde das bei mir dann auf mehrere "Joins" hinauslaufen. genre, besitzer, codec_vid, codec_aud usw.

Jetzt stell sich die Frage ob das wirklich sinnvoll ist, da ich die ganze Sache dann umprogrammieren müsste und noch dazu die bereits bestehenden Tabellen ändern müsste.
Die Queries selbst würden dann auch immer länger und unübersichtlicher werden.

Und wie siehts mit INSERT und UPDATE aus? kann ich da auch joins verwenden? Hab dazu nix brauchbares finden können

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.