[:en]Whenever you encounter a query slower than you expected, and you’re sure you’ve done everything in your power to ensure your tables are properly optimized and indexed, you might want to profile it. MySQL has an inbuild profiler, which allows you to see very detailed for what part of the query how much time has been spend.
To use it, follow these steps:
(1) Activate the profiler.
Since the profiler is deactivated by default we first have to start it.
[sql]SET profiling = 1;[/sql]
(2) Execute your query.
(3) Find out the query id for profiling.
[sql]SHOW PROFILES;[/sql]
It will return you something like this:
[sql]
Query_ID | Duration | Query
———+———–+———————–
… | … | …
29 | 0.0006200 | SHOW STATUS
30 | 0.3600000 | SELECT (your query here)
… | … | …
[/sql]
Now you know the query id is 30.
(4) Profile the query.
[sql]SHOW PROFILE FOR QUERY 30; // example [/sql]
This will return you the details, which might look like this:
[sql]
Status | Duration
——————————–+——————-
starting | 0.000010
checking query cache for query | 0.000078
Opening tables | 0.000051
System lock | 0.000003
Table lock | 0.000008
init | 0.000036
optimizing | 0.000020
statistics | 0.000013
preparing | 0.000015
Creating tmp table | 0.000028
executing | 0.000602
Copying to tmp table | 0.000176
Sorting result | 0.000043
Sending data | 0.080032
end | 0.000004
removing tmp table | 0.000024
end | 0.000006
query end | 0.000003
freeing items | 0.000148
removing tmp table | 0.000019
closing tables | 0.000005
logging slow query | 0.000003
cleaning up | 0.000004
[/sql]
In this example, most of the time was actually spend sending the data from the server back to the client. Maybe try narrowing down the amount of data you get from the query. Maybe raise your query cache. Maybe do something different – its entirely up to your database, server and needs what to make of this result. But now you know where to look!
[:de]Manchmal begegnet man einer SQL-Abfrage, welche langsamer ist als erwartet. Man weiß genau, alles wurde getan, dass die Tabellen optimiert und sauber indexiert sind. Und dennoch ist die Abfrage zu langsam.
Hier hilft Profiling.
MySQL verfügt über einen eingebauten Profiler, der es ermöglicht, sehr detailliert zu tracen, für welchen Bestandteil einer Abfrage die Datenbank wie lange genau gebraucht hat.
Um den Profiler zu verwenden, geht man wie folgt vor:
(1) Einschalten des Profilers.
Per Default ist der Profiler deaktiviert, daher muss man ihn erst starten.
[sql]SET profiling = 1;[/sql]
(2) Ausführen der eigentlichen Abfrage.
(3) Identifizieren der Abfrage-ID.
[sql]SHOW PROFILES;[/sql]
Dieses Kommando wird in etwa folgendes zeigen:
[sql]
Query_ID | Duration | Query
———+———–+———————–
… | … | …
29 | 0.0006200 | SHOW STATUS
30 | 0.3600000 | SELECT (your query here)
… | … | …
[/sql]
Jetzt weiß man, die Abfrage-ID ist 30.
(4) Profiling der Abfrage.
[sql]SHOW PROFILE FOR QUERY 30; // example [/sql]
Dies zeigt die Details der Abfrage.
[sql]
Status | Duration
——————————–+——————-
starting | 0.000010
checking query cache for query | 0.000078
Opening tables | 0.000051
System lock | 0.000003
Table lock | 0.000008
init | 0.000036
optimizing | 0.000020
statistics | 0.000013
preparing | 0.000015
Creating tmp table | 0.000028
executing | 0.000602
Copying to tmp table | 0.000176
Sorting result | 0.000043
Sending data | 0.080032
end | 0.000004
removing tmp table | 0.000024
end | 0.000006
query end | 0.000003
freeing items | 0.000148
removing tmp table | 0.000019
closing tables | 0.000005
logging slow query | 0.000003
cleaning up | 0.000004
[/sql]
In diesem Beispiel wurde die meiste Zeit der Abfrage damit verbracht, das Ergebnis an den Client zurückzusenden. Vielleicht sollte man die Ergebnismenge reduzieren, oder ggf. den Query Cache erhöhen. Vielleicht geht man aber auch ganz anders vor, hier sollte man von Fall zu Fall prüfen, was sinnvoll und möglich ist.
Aber dank dem Profiling weiß man nun, wo man suchen muß!
Schreibe einen Kommentar