mySQL zu langsam?

[TheMaxx]

Hoffe hier sind ein paar mySQL Spezies, die mir helfen können :)

Ich hab eine mySQL-Kundendatenbank gebastelt, die ca. 750 Tabellen beinhaltet (Tabellen haben bis zu 160.000 Einträge - bis zu 60 MB groß). Mit PHP hab ich eine Vollsuche geschrieben, die alle Tabellen komplett nach einem Suchstring durchsucht.
Mein Problem ist die Geschwindigkeit. Kann es sein, dass das ganze auf einem P4 1600 MHz gut 5 Minuten dauert???
Zugegeben, es ist ne Menge an Daten, die er da durchsuchen muss. Aber wie ist das hier z.B. mit der Forumssuche oder die Suche z.B. bei google - das sind doch sicher auch mehrere 100 MB (oder noch mehr), die da durchsucht werden. Und das ganze dauert oft nur wenige Sekunden.

Kommentare?

[Captain America]

750 Tabellen? :lol:

Wie auch immer, lies dir mal im MySQL Handbuch die Kapitel über Indices (Index) und Volltextsuche durch.

[Marcel]

Wie sehen die Anfragen denn aus? Fragst Du jede Tabelle einzeln ab oder alle in einer einzigen Mega-Join-Query? Wieviel davon geht auf indizierte Felder? Hat der Rechner genug Speicher?
MySQL ist zwar kein vollständiges DBMS nach Codd, aber so scheiße sollte es eigentlich nicht sein.

Auch nicht uninteressant: Wie sieht der PHP-Teil aus? Selbst wenn PHP4 durch sein Pre-"compiling" deutlich schneller geworden ist, die Performance-Krone sieht es noch lange nicht, die bleibt bei Native Compilern.

Gruß,
Marcel

[Captain America]

Originally posted by Marcel
MySQL ist zwar kein vollständiges DBMS nach Codd, aber so scheiße sollte es eigentlich nicht sein.


;D

MySQL = :pukeface:

Was mich noch mal interessieren würde: wie kommst du auf 750 Tabellen? Entweder willst du uns auf den Arm nehmen, oder du hast nicht verstanden wie man eine RDBMS sinnvoll gestaltet.

[Marcel]

Originally posted by Captain America
;D

MySQL = :pukeface:


Na, na, na! MySQL ist zwar nicht in derselben Liga wie Oracle oder DB2, aber selbst diejenigen, die es als Karteikasten bezeichnen, stapeln auch tief. MySQL ist für Webseiten ganz nett. Ein Smart ist ja auch keine vollständige Allzwecklimousine, aber als Pizzataxi ganz nett.

Originally posted by Captain America

Was mich noch mal interessieren würde: wie kommst du auf 750 Tabellen? Entweder willst du uns auf den Arm nehmen, oder du hast nicht verstanden wie man eine RDBMS sinnvoll gestaltet.

Eine sehr interessante Frage. Will da etwa jemand zu großen Tabellen aus dem Weg gehen? Sinnvolle Datenaufteilung bei gleicher Struktur gehört immer noch durch vernünftiges Primärschlüsseldesign gelöst.

Gruß,
Marcel

[TheMaxx]

Nix für ungut, aber den Datenbankaufbau möchte ich hier nicht weiter erläutern. Und nein ich will hier niemanden aufn Arm (nur ein bißchen weniger arrogantes Von-oben-herab wäre nett @Capt)

Wie sehen die Anfragen denn aus? Fragst Du jede Tabelle einzeln ab oder alle in einer einzigen Mega-Join-Query? Wieviel davon geht auf indizierte Felder? Hat der Rechner genug Speicher?

Bin noch kein PHP-Meister deswegen hab ich das mit der Abfrage z.zt. so gelöst, dass ich erst einmal alle Tabellen in ein array schreibe und dann in einer Schleife auf jede Tabelle die SELECT Abfrage starte. Findet er etwas dann gibt er den Tabellennamen aus und geht zur nächsten Tabelle über.

Von der Spaltenindizierung hab ich zwar schon gehört aber noch nicht weiter mit befasst. Ich denke das werde ich als nächstes mal in Angriff nehmen.

Rechner hat übrigens 512 MB Ram.

Da ich erst next week wieder bei der Arbeit bin werd ich mir das auch erst am Montag nocheinmal anschauen können.

[Marcel]

Originally posted by TheMaxx
Von der Spaltenindizierung hab ich zwar schon gehört aber noch nicht weiter mit befasst. Ich denke das werde ich als nächstes mal in Angriff nehmen.
[...]
Da ich erst next week wieder bei der Arbeit bin werd ich mir das auch erst am Montag nocheinmal anschauen können.

Dort sollte dann - nach der Kaffeemaschine und dem WC - die MySQL-Doku zum Thema Indizes tatsächlich das allererste Ziel sein. Vor allem die Volltextindizes. Sprich, Kapitel 5 und 6.8 .

Gruß,
Marcel

[Marcel]

Originally posted by Marcel
Vor allem die Volltextindizes. Sprich, Kapitel [...] 6.8 .


Oder habe ich Dich falsch verstanden und Du wolltest keine Volltextsuche machen? Dann kannst Du das Kapitel 6.8 nämlich vergessen.

[Captain America]

Originally posted by TheMaxx
Nix für ungut, aber den Datenbankaufbau möchte ich hier nicht weiter erläutern. Und nein ich will hier niemanden aufn Arm (nur ein bißchen weniger arrogantes Von-oben-herab wäre nett @Capt)



Bin noch kein PHP-Meister deswegen hab ich das mit der Abfrage z.zt. so gelöst, dass ich erst einmal alle Tabellen in ein array schreibe und dann in einer Schleife auf jede Tabelle die SELECT Abfrage starte. Findet er etwas dann gibt er den Tabellennamen aus und geht zur nächsten Tabelle über.

Von der Spaltenindizierung hab ich zwar schon gehört aber noch nicht weiter mit befasst. Ich denke das werde ich als nächstes mal in Angriff nehmen.

Rechner hat übrigens 512 MB Ram.

Da ich erst next week wieder bei der Arbeit bin werd ich mir das auch erst am Montag nocheinmal anschauen können.

Sorry falls es arrogant angekommen ist, es war nie so gemeint. Ich arbeite als Programmierer und bilde mir ein, mit der gesammelten Erfahrung hilfreich sein zu können! ;)

Also, noch mal zur Anzahl der Tabellen: 750 Stück erscheint zu viel. Ich kann mir keine Software vorstellen, die so etwas wirklich braucht. Erklär uns bitte soweit wie Möglich was zu 750 Tabellen führt.

Zur Suche / PHP: Falls du Tabellen verknüpfst per JOIN, solltest du auf jeden Fall Indizieren. Wenn du kannst, poste ein Stück PHP-Code, evtl finden wir da eine Bremse.

Speicherst du BLOBs in den Tabellen? TEXT oder VARCHAR?

Auch bedenklich: bei so vielen Tabellen kann es sein, dass die Systemressourcen zu neige gehen. Welches OS nutzt du? Prüf mal den Speicherverbrauch von MySQL, Webserver und PHP, die CPU-Zeit, und evtl. offene Dateidescriptoren. Unter Unix ist das Programm "lsof" empfehlenswert.

Und ganz wichtig: das EXPLAIN Statement. Es zeigt dir an, wie du eine Abfrage verbessern kannst, bzw wo lange Wartezeiten entstehen. Das Handbuch ist dein Freund!

[Wuzel]

Zum speed :
Wie bei allem DB zeug : zwei ( oder mehr ) kleine protzis sind besser als ein grosser, das sogar in manchen fällen extremst.

Dann würd ich mir InoDB tabels anschauen http://www.mysql.com/documentation/mysql/bychapter/manual_Table_types.html#InnoDB

Das könnts reissen.
PHP ist für sowas nicht immer gut, perl kann hier noch mal nen paar Prozent ziehen und naja C wäre das schnellste, geht sogar manchmal nicht anders.

[Elvin]

750 Tabellen ???

Das hat meine Neugier geweckt. Welches Problem hat solch eine Menge Tabellen verdient.
Hast du dort für jeden Mitarbeiter eine Tabelle angelegt??? :)
Oder schreibst du ein Verwaltungsprogramm wo du die Adressen, Urlaube, Hobbys, Firmenwagen, Privatwagen und Raumverwaltung und was alles noch so zu einer Firma gehört??? :)

Erkläre doch mal bitte grob was das für Tabellen sind oder man kann sie vielleicht auch in Gruppen aufteilen (dann erklär die).
Aber bitte erklär uns das, bitte bitte.

Bis dann

[TheMaxx]

Um die Struktur grob anzureissen, ich habe eine DB mit Kunden und deren Kunden. Und ich hab es mir einfach gemacht und für jeden Kunden eine eigene Tabelle erstellt (in der dann die Kunden unserer Kunden stehen).
Ich weiß da hätte man noch normalisieren können (bzw. müssen!), aber das hätte alles nur komplizierter gemacht und ich wollte es nicht unnötigerweise verkomplizieren um mehr Performance zu bekommen. Es läuft auch soweit ganz gut im Moment, also bleibts so.
Nächstes Mal dann aber (man lernt ja nie aus!).

--- co... co... closed ---

[Marcel]

Nun, die Performance-Aspekte hätte man sicherlich durch mehrdimensionale Primärschlüssel oder passende Sekundärschlüssel in den Griff bekommen, behaupte ich angesichts meiner nicht tiefgehenden Kenntniss der Datenstruktur ziemlich selbstbewusst.
Allerdings scheinst Du ja nicht ganz unbeflekt in Sachen DB-Design zu sein, wenn Du das Thema Normalisierung auf diese Weise ansprichst, zudem gelobst Du ja anscheinend Besserung... ;-)

Wenn die Daten in tausend12 gleichartige Tabellen verteilt sind, ist halt die Programmierung etwas fummeliger, deswegen sehe ich von sowas gerne ab. Mein letztes Projekt mit solchen Strukturen konnte ich zum Glück ziemlich schnell wieder abstoßen.

Gruß,
Marcel

[Elvin]

Alles klar :idea:
Unter diesen Umständen ist es auch nicht verwunderlich das deine Anwendung bzw. deine Datenbankzugriffe so langsam sind. Ich denke nicht das du über das Program die Geschwindigkeit verbessern kannst.
Wenn du die Geschwindigkeit erhöhen willst musst du wohl oder übel die Datenbank umstrukturieren. :D

Was ich nur nich versteh wenn du Ahnung von Datenbankstrukturen hast bzw. den Begriff Normalisierung kennst, (was ja schon was heißt) warum vernachlässigst du dann sowas wie Performance ??? (gerade bei so einer Menge von Datensätzen)
Ich mein so kompliziert die Struktur auch sein mag, es erspart dir im nachhinein ne menge Arbeit.

Außerdem kann das nicht so schwer sein, wenn man da ein paar Stunden drüber grübelt sollte so eine Struktur schnell zu stande kommen, der Rest is ja dann ein Kinderspiel.
:jump2:
Naja es wird dir ja wohl ne Lehre sein.

:sniper: