[robo47]

Also ich mache mir momentan darüber Gedanken die Datenbankabfragen eines Scriptes zu optimieren und denke da insbesondere an das setzen von Indizes auf Spalten, dazu wollte ich wissen ob es bei mySQL möglich ist, eine Art Statistisches Logging darauf zu machen, welche Spalten mehrfach im WHERE-Teil von abfragen auftauchen, vielleicht gibt es auch fertige Lösungen die beispielsweise mysql-logs auswerten zu diesem Zweck.

Ich bin mir zwar im klaren darüber, welche Spalten in meinen Querys abgefragt werden und auch welche wohl relativ oft, aber ich dachte daran dass sich Theorie und Praxis zu oft unterscheiden und wollte deshalb Produktivsysteme in dieser Form einfach mal für 1-2 Monate überwachen, weil ich denke, dass mir dies bessere Informationen darüber gibt, wie die Belastung der Datenbank wirklich ist und wo man sinnvoller Weise eher Indizes setzt, Dinge an der Datenbank ändert oder auch andere Optimierungen durchführen kann.

Vielleicht hat jemand ja in dem Bereich Erfahrungen, kennt (möglichst kostenlose) Tools die einem sowas ermöglichen oder kennt andere Tips die mir beim meinem Problem helfen.

mfg
robo47

[Ben]

Kenne jetzt keine Tools, aber vielleicht hilft dir ja die Auswertung dieses speziellen Logfiles?

5.11.5. The Slow Query Log
http://dev.mysql.com/doc/refman/5.1/...query-log.html

[robo47]

Slow Query Log ist mir bekannt, aber es sind halt keine wirklich lang dauernden Querys, mir gehts es mehr um alle Querys.

[Bleistift]

Hm... Ich würde das direkt in der Applikationen mit einem DB-Profiler machen.
Du kannst ja direkt in der Klasse, die die Applikation für die SQL-Abfragen nutzt, die Queries () aufzeichnen und später dann auswerten.

[robo47]

Zitat von Bleistift

Hm... Ich würde das direkt in der Applikationen mit einem DB-Profiler machen.
Du kannst ja direkt in der Klasse, die die Applikation für die SQL-Abfragen nutzt, die Queries () aufzeichnen und später dann auswerten.

Hmm ich frag mich dabei, was schneller und einfacher ist, mysql einfach alle querys mitloggen zu lassen oder einen DB-Profiler das während der Laufzeit machen zu lassen, aktuell würde ich das aufzeichnen wohl bevorzugt von SQL selbst machen lassen.

mfg
robo47

[mepeisen]

Zitat von robo47

Hmm ich frag mich dabei, was schneller und einfacher ist, mysql einfach alle querys mitloggen zu lassen oder einen DB-Profiler das während der Laufzeit machen zu lassen, aktuell würde ich das aufzeichnen wohl bevorzugt von SQL selbst machen lassen.

Schneller und einfacher ist das, was schneller und einfacher ist. Klingt blöd, ist aber so. Zunächst einmal kommt das ganze stark darauf an, wo die Performance-Probleme herrühren. Da man das aber nie (oder nur selten) wirklich weiß vor der nalyse, kann man eigentlich nicht zielgerichtet analysieren.

Glücklicherweise gibt es im klassischen Umfeld vier Ursachen für Performance-Probleme.

1. Keine Index-Nutzung
Selbst bei kleinen Tabellen mag das sinnlos erscheinen, einen Index zu erstellen. Aber nutzt man rege JOINs und ergeben sich damit für das SQL permutiert sehr sehr viele Ergebnis-Datensätze oder verjoint man mit einer sehr großen Tabelle, können Indizes einen Sinn ergeben.

2. Zu große Datenmengen
Jedes Datenbanksystem hat Optimierungen. Aber irgendwann stolpert jedes Datenbanksystem über zu große Datenmengen.

3. zu große temporäre Tabellen
Ein Optimizer hat irgendwann Probleme, wenn Subselects rege genutzt werden. Selbst wenn die resultierende Datenmenge klein ist. Sind die temporären Datenmengen eines Subselects gigantisch, stolpert jedes noch so tolle Datenbanksystem.

4. zu viele Selects
Gerade Anfänger nutzen eigentlich eher selten einfachste Joins. Die Folge sind oft Verschachtelungen mehrerer Selects, wobei dann die inneren Selects gleich hundertfach oder tausendfach ausgeführt werden pro Request.


Im Grunde kann man das ganze also zweiteilen:
- Häufigkeit von Selects
- Langläufigkeit von Selects
Bei beiden stellt MySQL bereits Techniken zur Verfügung, um so etwas herauszufinden. Wie man es tunen kann, kommt dann immer auf die konkreten Fälle an: http://dev.mysql.com/doc/refman/5.1/en/query-speed.html

[robo47]

Es ist ja nicht so, dass es aktuell Performance-Probleme gibt, es ist viel mehr so, dass ich gerne schauen würde ob sich ein bestehendes System eventuell weiter optimieren lässt.

[mepeisen]

Zitat von robo47

Es ist ja nicht so, dass es aktuell Performance-Probleme gibt, es ist viel mehr so, dass ich gerne schauen würde ob sich ein bestehendes System eventuell weiter optimieren lässt.

Das ist ja wurscht. In deinem Fall wendest du halt einfach deutlich sensiblere Kriterien an, also was Laufzeit und Häufigkeit eines SQLs angeht.

Das ist einfache Mathematik: Ein SQL, der 2 Millisekunden braucht, wird sich kaum tunen lassen. Der Aufwand ihn zu tunen, ist zu hoch. Dann tunt man lieber einen SQL, der 15 Sekunden dauert. Denn den kann man vielleicht so tunen, dass er nur noch 0,1 Sekunden dauert. Der Nutzen ist groß.

Umgekehrt: Wird der SQL von 2 Millisekunden Länge in der Minute 5 Millionen mal aufgerufen, der SQL von 15 Sekunden aber nur einmal am Tag, tunt man doch lieber den "schnellen" SQL. Dann halt vielleicht mit einem Cache oder ähnlichem.