Hi,

ich möchte ein kleines Paper zum Thema 'MySQL Anwendungen beschleunigen' schreiben.

Es gibt natürlich Bücher und Websites, aber einige [einfachere] Techniken könnten gut mal in _einem_ Paper zusammengefasst werden.

Falls jemand Tips und Hinweise hat, dann schreibe er doch in diesen Thread. Links zu Sites und Tool wären interessant, SQL code und DB Konfigurationen.

Thx,

sp

Ah, vergessen: Ich weiss, das Thema ist an sich komplex. Bitte keine Anmerkungen der Art 'Was soll das....'

spontan fallen mir da folgende stichworte ein (fürs erste):

- effizienter php-code (da sollte sich so einiges ergooglen lassen)
- ordentlich normalisiertes, aber nicht übertrieben "granulisiertes" db-modell
- systemoptionen (speicherzuteilung, php.ini, mysql-conf) - da lässt sich einiges tunen - und auch hier lässt sich so einiges ergooglen...

ich denke, wenn du die drei zweige als grundlage nimmst und anhand der stichworte googlest, bist du schon auf dem richten weg...


gute nacht,
der chris.

Thx! Ja, das ist neben diversen Büchern, Blogs etc. natürlich auch mein Weg - Google.

Neben der schon erwähnten effizienten Gestaltung der Abfragen fällt mir noch spontan das Pooling der Verbindungen zur Datenbank ein. Die meisten webzentrierten (und MySQL-gespeisten) Anwendungen, die ich bis dato gesehen habe, kranken ehr am Problem des Verbindens mit der Datenbank, als am eigentlichen SQL...

Dein Vorschlag ist also pconnect, statt connect? Oder meinst Du die mySQL Konfiguration selber?

Die Verwendung von 'pconnect' wäre ein Weg, wenn man denn PHP verwendet. Unter Java und JDBC gibt es etwas. das viel weiter geht. Dort initialisiert man eine "Handvoll" Verbindungen beim Applikationsstart, stopft die in den applikationsweiten Scope und entnimmt sie bei Bedarf um sie nach Verwendung wieder zurückzulegen, aber NIE zu schliessen... Das macht besonders bei Webanwendungen mit vielen konkurrierenden Zugriffen "Riß".

Ich habe z.B. mit
> set global query_cache_size=10000000;
mal eine Anwendung erheblich beschleunigt.
Ich kenne mich selber aber nicht so gut mit MySQL aus.

Und dann fallen mir noch "prepared statements" ein...

Und "stored procedures". Zumindest seit MySQL 5.x

planetexpress69<br>
Bringen 'stored procedures' wirklich viel? Führt der Server automatische Updates der Queries durch und hält die Ergebnismenge dadurch immer aktuell? Oder wird der query analyser dadurch beeinflusst?

HR<br>
Thx! Wichtiger Hinweis, denn die alleinige Aktivierung des Query-Cache durch 'ON' aktiviert den Cache nicht. Die Größe muss auf einen Wert >0 eingestellt sein.

planetexpress69<br>
Ja, das kenne ich. Ist auch sehr sinnvoll, aber leider unter PHP nicht möglich. Und ich bin an PHP gebunden...

Wie @@planetexpress69 bereits schreib: effiziente Queries (z.B. Joins statt unzählige SubSelects) sind das A und O.

Als wesentliche Maßnahme kann ich nur immer wieder empfehlen, der Datenbank so viele Aufgaben wie möglich zu überlassen.
Allzu oft habe ich schon Anwendungen gesehen, in denen reihenweise Daten aus der DB gezogen werden, welche dann anschliessend von der Anwendung für weitere Berechnungen benutzt wurden, die die DB leicht in einem Bruchteil der Zeit hätte erledigen können.
Bestes Beispiel ist das anschliessende Summieren von abgefragten Werten.

Außerdem kann ein guter QueryCache sehr viel rausholen.
Habe aber leider keine Ahnung, wie der bei MySQL zu optimieren und zu benutzen ist. (arbeite hauptsächlich mit Firebird)

seaside<br>


Kann man via pconnect nicht auch mehrere Connections offen halten? Habe es so in Erinnerung.

Btw: mich würde das fertige "Paper" mal interessieren.

stiffler<br>
Mit der Syntax

EXPLAIN <hier die SELECT query>

erhält man Informationen, was der Query Analyzer zur Query meint. Konkret wird beispielsweise angezeigt, ob ein Index genutzt wird, oder die ganze Tabelle gelesen werden muss [table scan].

Ausserdem sollte man, wenn man lang laufende Queries hat, den Slow-query-cache in der my.cnf aktivieren, da MySQL dann langsame Queries in ein log schcreibt.

Prepared Statements behalten IMHO die Queries (nicht deren Ergebnismengen!) im Cache der DB. Vorteil ist, dass bei Wiederbenutzung nur noch die (u.U. geänderten "Argumente" zur DB übertragen werden müssen. Das geht schneller als das Übertragen der gesamten Query.

Übrigens: Ich kenne kenne eine ziemlich datenbanklastige PHP-Site (mit MySQL im Backend), wo der QueryOptimizer fein säuberlich abgeschaltet wird, weil er sich bei bestimmten JOINs gerne mal vertut...

<snip>
Kann man via pconnect nicht auch mehrere Connections offen halten? Habe es so in Erinnerung.
</snip>

Du kannst in einem PHP-Skript auch sechzig Connections per pconnect aufmachen, aber dann? Der Haken ist, dass PHP zwar globale Variablen in einem Skript zuläßt, aber leider eben nur per Skript und nicht applikationsweit... So heißt es: neuer Request, neues Spiel...

Was man mit PHP machen kann (rein akademisch): Du initialisierts eine Connection per Session, registrierst sie und verwendest die fein für jeden Request dieser Session. Geschlossen wird sie dann erst beim Beenden (oder Timeout) der Session. Das bedarf aber einer Menge Fingerspitzengefühl, weil ja auch jemand 'ab -c100 http://foo.bar/something.php' machen könnte...

Im Übrigen schliesse ich mich der Stiffler-Meinung an: Möglichst viele Dinge die DB machen lassen! Ein gutes SQL-Buch kann da sehr inspirierend sein; zur Not tut es auch die Befehlsreferenz.

Ergebnismengen möglichst so genau liefern lassen, wie man sie braucht. Nicht alles geben lassen und dann konditional im Skript verwerfen! HAVING nutzen. Indizes schlau setzen. Dabei auch immer an das "teure" INSERT denken! Wenns schnell gehen soll (SELECT), auf variable Feldlängen verzichten...

Und bei JOINs immer schön den konditionalen Charakter des Teils rechts der WHERE-Klausel im Kopf behalten:
WHERE kleine_ergebnismenge AND große_ergebnismenge oder
WHERE große_ergebnismenge AND kleine_ergebnismenge ???

planetexpress69<br>
Bestätigt. Selbst beim expliziten FORCE des fraglichen Index tut sich nix. MySQL führt ständig einen table scan durch.

Hm, muss ich mir noch mal ansehen...