PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Lahmes MySQL


Vagabundo
01.08.2007, 23:22:45
Hallo,

ich arbeite schon laenger mit einem MySQL Table mit ca Fields, die meisten davon sind varchar

Inzwischen haben sich da fast 700.000 Datensaetze angesammelt.

Wenn ich nun mit phpmyadmin etwas in dieser table nachsehen muss habe ich sehr lange Zugriffszeiten (besonders, wenn ich ans Ende springe) 10 - 70 Sekunden.

Ist es moeglich, dass dieses Verhalten mit den varchar Felder zusammenhaengt? Ich meine ich habe irgendwo mal gelesen, dass es fuer die Performence besser waere mit char Feldern zu arbeiten.

Das phpmyadmin legt aber bei jedem Feld das groesser ist wie 2 oder 3 Felder ein varchar an, egal, was man eingibt.
Ich habe auch schon versucht die Feldtypen auf char zu aendern, aber er roedelt ewig rum und es sind dann doch wieder varchars.

Meine Fragen:

1. Koennen die varchars die Performance wirklich so stark beeinflussen

2. Wie bekomme ich mit dem phpmyadmin char Felder hin (sofern es ueberhaupt sinnvoll ist.)

Danke fuer Eure Tips.

Christian

Raketenmann
02.08.2007, 12:42:29
ich arbeite schon laenger mit einem MySQL Table mit ca Fields

Wieviele Felder sind es denn ca...?

die meisten davon sind varchar


...und überwiegend mit langen Strings gefüllt?!?


Ein VarChar-Feld benötigt mindestens 1 Byte pro Zeichen, da kannste ja mal ausrechnen wie es um die physikalische Größe deiner Datenbank bestellt ist, wenn da 700.000 Datensätze drinstehen...

Ich glaube das ist eher dein Geschwindigkeitsproblem.

Ob es sinnvoll ist Char statt VarChar zu nehmen, hängt von deinen Inhalten ab (auch von den bislang vorhandenen zig tausend) - beides hat Vor- und Nachteile.

Vagabundo
02.08.2007, 14:31:57
Hallo,

ja, ich wollte noch nach den Feldern sehen und habe es dann aber vergessen. Es sind 38 Felder und davon 22 varchar. Die Fuellung der Felder ist ganz unterschiedlich.

Aber es geht nicht um die Groesse der Table, das spielt nur eine geringe Rolle, sondern um die Zugriffszeit.

Ich denke wenn es z.B. keine Varchars geben wuerde koennte sie ja sehr einfach ans Ende springen und muesste viel schneller sein - oder stimmt das nicht?

Ich denke ueber 1 Minute ist einfach zu lang, nur um im phpmyadmin die letzte Seite mit 30 Datensaetzen anzuzeigen. (Die angegebenen Zeiten sind natuerlich nur die von phpmyadmin ermittelten Zugriffszeiten auf die Datenbank).

Christian

Raketenmann
02.08.2007, 14:39:39
Aber es geht nicht um die Groesse der Table, das spielt nur eine geringe Rolle, sondern um die Zugriffszeit.


Doch es geht um die Größe der Tabelle, denn davon hängt die Zugriffzeit u.a. ab...

Sicher werden Char-Felder schneller verarbeitet als VarChar-Felder,....
...aber vor allem wird die Verarbeitung der Tabelle mit jedem MB, dass dazu kommt, ein bißchen langsamer.

Ich kenne deine Tabelle nicht, aber nach der Beschreibung dürfte da dieses oder jenes MegaByte zusammengekommen sein.

Dies ist einer der Gründe aus denen man große Informationsmengen auf mehrere Tabellen aufteilt.

diver-network
03.08.2007, 17:34:21
Hi,

zuerst mal sind mehrere MB große MySQL Tabellen kein Problem, was die Performance angeht.
Ich tippe eher auf nicht vorhandene oder falsch gesetzte Indizes. Wenn MySQL für den SELECT erst mal die komplette Tabelle ohne Index durchsuchen soll stimmt die Formel "je mehr Daten = je langsamer" natürlich.

Fazit: Schau mal nach Deinen Indizes.

HTH,

Andy

FabianWesner
03.08.2007, 20:48:41
zuerst mal sind mehrere MB große MySQL Tabellen kein Problem, was die Performance angeht.
Ich tippe eher auf nicht vorhandene oder falsch gesetzte Indizes. Wenn MySQL für den SELECT erst mal die komplette Tabelle ohne Index durchsuchen soll stimmt die Formel "je mehr Daten = je langsamer" natürlich.

Das seh ich auch so, denn beim reinen Anzeigen gibt es eigentlich nix was berechnet werden müßte... unabhängig von der Anzahl an Einträgen. An den varchars liegt es sicher nicht, solange man keine Volltextsuche mit %% macht.

@Vagabundo
Poste doch mal bitte die Struktur des Tables.

Socrates
03.08.2007, 20:56:25
Abend!
Welchen Anbieter hast du denn? ich hatte früher meine DBs von db4free und da hat es teilweise noch länger gedauert und ich hatte so gut wie keine Datensätze. Den Anbieter gewechselt und schon geht alles wie am schnürchen. nur ne Idee!
MfG, Andy

Raketenmann
06.08.2007, 12:37:46
zuerst mal sind mehrere MB große MySQL Tabellen kein Problem, was die Performance angeht.


...habe ich auch nicht behauptet.
Meine Antwort bezog sich auf eine Riesentabelle, die ich auf einem Server liegen habe. Da dauert so ein Sprung an Ende der Tabelle auch gerne mal runde 10 Sekunden und die hat einen numerischen Index - ohne die Indexspalte dauert die gleiche Aktion ca. 25 Sekunden oder länger.

Die Tabelle enthält aktuell 1.222.390 Zeilen bei einer Größe von fast 118 MB (der Index Anteil beträgt dabei knapp 10 MB) und sie enthält folgende Spalten: INT(11), INT(11), VARCHAR(15), VARCHAR(4), VARCHAR(255), VARCHAR(255).

Wenn Vagabundo 22 von 38 Spalten als VARCHARs definiert und auch ordentlich füllt, z.B. eine durchschnittliche Zeilenlänge von über 100 erzeugt, geht es bei 700.000 Datensätzen nicht um ein paar MB, sondern eher um eine Größenordnung, die sicher oberhalb meiner liegt.

Dies hat auch bei MySQL-Servern Performance Einbußen zur Folge, besonders wenn man nicht der Einzige ist, der den Server mit Anfragen "nervt". ;-)

Aber zweifellos habt ihr recht damit, dass die Definition eines Index die Verarbeitungszeit erheblich senkt.