Komplexere MySQL-Abfragen, Performance

[zorkez]

Hallo,

ich arbeite gerade etwas an einem privaten Projekt und dafür habe ich mir eine DB (innoDB-engine) aufgebaut die die referenzielle Integrität gewährleisten soll und Redundanzen gering hält.

Zu meinem Problem:
Ich will Streams verwalten. Die Informationen dazu hole ich mir über 7 Tabellen die ich mit joins verbinde.
Die Anfrage ist recht komplex deshalb schreib ich die hier net rein, da es um eine Verständnisfrage geht.

Leider schaffe ich es nicht alle Informationen mit einem SQL-Satement zu erhalten, die ich benötige.
Es gibt noch ca. 5 weitere Tabellen die sich z.B. um die Klicks der einzelnen Hoster kümmern etc.

Meine Frage dazu ist jetzt:
Ist es schlimm wenn ich mehrere SQL-Statements ausführen muss?

Hat jemand Erfahrung wie sich das auf die Performance auswirkt?

Mit den 7 Joins über eine Tabelle erreiche ich bei wenig Daten in der Tabelle ca. 0,01s
Das steigt bei wachsender Datenmenge noch ziemlich in die Höhe. Aus diesem Grund habe ich Caching eingeschaltet.

Wenn ich das auf mehrere Statements verteile sieht das etwa so aus:

Join mit 7 Tabellen:
Kategorie: 5000 Einträge
dazugehörige Schauspieler und sonstige Besetzungen (2 Tabellen): 3000 Einträge
etc.

Join mit 5 Tabellen:
Links: Mehrere Zehntausend
-- Die Links enthalten jeweils mehrere Parts
-- Die Parts wiederum enthalten mehrere Hosts (also bei wem das ganze gehostet wird)
etc. pp.

Ich denke die Tabellen sind alle Normalisiert und die Indizes sind alle gesetzt wo sie hin sollen.

Kann ich nach diesem Schema vorgehen, ohne später mit Problemen rechnen zu müssen?

Zu dem Caching habe ich mir das so gedacht, dass ich Versuche die Abfragen zusammenzufassen, die selten geändert werden, damit diese im Arbeitsspeicher schnell zugreifbar sind.
Andere die sich ständig ändern z.B. die Klicks auf einen Hoster zum Beispiel werden ja bei jedem Aufruf der Seite geändert und damit würde das Caching nichts bringen.
Mein Ansatz wäre diese Statements dann so klein wie möglich zu halten.

Sag mal bitte jemand was dazu. Hab mich da mal bisschen eingearbeitet und blicke da noch nicht ganz durch.

Danke im Voraus und habt Nachsicht mit meiner Unwissenheit.

MfG

[phpBuddy]

Hallo zorkez,

so komplex deine Abfragen sind, so wenig kann man deine Fragen beantworten. Da hilft nur testen, Log files auswerten, benchmarken, usw.

Ist es schlimm wenn ich mehrere SQL-Statements ausführen muss?

Jein. Sprechen wir hier über 5 oder 5.000 zusätzliche Anweisungen und werden die bei 10 oder 10.000.000 Zugriffen am Tag ausgeführt? Ebenso ist uns auch nichts bekannt über die Komplexität der (zusätzlichen) Abfragen.
Bei simplen Select-Statements, die sagen wir mal, grob im Bereich von 5 bis 10 zusätzlichen Queries liegen, die bei ca. 10.000 Zugriffe pro Tag ausgeführt werden, würde ich mir jetzt nicht soooo viele Sorgen machen.

Man so als Beispiel. Die vBulletin Forum Software führt bei jedem Seitenaufruf mehr als 65 Queries aus. Bei jedem Klick, für jeden User. Schau dir mal richtig große Boards an, wobei das Traum-Projekt ja auch nicht sooo klein ist. Würdest Du sagen, dass diese Seiten sonderlich zäh und langsam laufen?

Hat jemand Erfahrung wie sich das auf die Performance auswirkt?

Generell wirkt sich jede zusätzliche Aktion negativ auf die Performance aus. Ob sich die Zusatzbelastung jetzt in Nanosekunden oder in zusätzliche Kaffeepause ausdrückt, ist individuell. Hier helfen nur (Belastungs)Tests und das Abwägen von Performance Einbuße vs Nutzen.
Außerdem ist meistens der wichtigste Faktor der Server selbst. Du kannst optimieren was Du willst, auf einer Shared Hosting Kiste, die Du dir mit 1.000 anderen Kunden teilst, hast Du recht wenig Chancen eine wirkliche High Performance Application zu realisieren.

Ich denke die Tabellen sind alle Normalisiert und die Indizes sind alle gesetzt wo sie hin sollen.

Das kannst nur Du beurteilen, da wir hier wieder absolut nichts über die Struktur der Tabellen wissen. Aber es ist schon mal ein guter Anfang, wenn Indizes gesetzt sind. Ansonsten kann man sehr viel Performance herausholen, wenn man nach möglichkeit viel mit TinyINT arbeitet, wo es möglich ist und mit ENUMs, die intern ebenfalls wie TinyINT behandelt werden. Suchen über solche Spalten bringen häufig Boosts von mehreren hundert Prozent gegenüber VARCHAR. Ebenso bringt es sehr viel, CHAR mit fixer Länge zu benutzen statt VARCHAR/TEXT mit variabler Länge.
Aber da brauche ich nicht viel zu erklären, es gibt unzählige Webseiten und Blogs, die sich auf solche Performance Dinge spezialisiert haben.

Kann ich nach diesem Schema vorgehen, ohne später mit Problemen rechnen zu müssen?

… kram krusch, ja wo ist denn die verdammt Glaskugel schon wieder? …

Mein Ansatz wäre diese Statements dann so klein wie möglich zu halten.

Das ist immer sinnvoll, aber man kann Anwendungen auch kaputt optimieren, also immer schön aufpassen.

Sag mal bitte jemand was dazu.

Erledigt!

[zorkez]

Super. Danke für deine Antwort.

Im Prinzip wollte ich nur wissen, ob ich mich auf dem Holzweg befinde, oder in die richtige Richtung gehe.

Also das ganze wird 5-10 Queries nicht übersteigen und wenn ich mit Caching arbeite, sollte das auch kein Problem darstellen.

Ich hab heute nochmal meinen Prof. damit genötigt. Der hat eigentlich das gleiche gesagt und ich bin mit dem auch auf das Hosten zu sprechen gekommen.
Da ich ja für Caching sehr wahrscheinlich root-rechte brauche und diverse Größen des Speichers selbst einstellen und optimieren muss, wird wohl nichts an einem Root-Server vorbeiführen.

Wie gesagt, ging es mir um ne Verständnisfrage. Probleme mit dem Stmt an sich hab ich ja keine und ich denke das würde auch eher verwirren.

Konkrete Aussagen habe ich nicht erwartet. Das ist durch meine recht allgemein gehaltene Problembeschreibung auch nicht möglich.


Danke nochmal für die Antwort.