Hallo zusammen,
ist es möglich bestimmte wichtige Laufzeitinformationen wie
"Handler_read_rnd_next"
"Qcache_lowmem_prunes"
"Created_tmp_disk_tables"
"Select_full_join"
"Select_range_check"
so zu loggen, dass ich die passenden SQL-Queries schnell finden kann?
Die slow_query-Möglichkeit hilft mir relativ wenig, da das Logfile
schnell mehrere MB groß ist ;)
Viele Grüße
Martin
Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)
Andreas Kretschmer schrieb:
> begin Martin Zemke
>> Die slow_query-Möglichkeit hilft mir relativ wenig, da das Logfile
>> schnell mehrere MB groß ist ;)
>
> grep wurde auch für Dich erfunden.
>
>
> end
> Andreas
Damit meinte ich, dass ich im slow-query-Log keine Unterscheidung
zwischen den verschiedenen Gründen hab, warum es in dem Log drin steht.
Martin Zemke schrieb:
> Hallo zusammen,
>
> ist es möglich bestimmte wichtige Laufzeitinformationen wie
> "Handler_read_rnd_next"
> "Qcache_lowmem_prunes"
> "Created_tmp_disk_tables"
> "Select_full_join"
> "Select_range_check"
> so zu loggen, dass ich die passenden SQL-Queries schnell finden kann?
>
> Die slow_query-Möglichkeit hilft mir relativ wenig, da das Logfile
> schnell mehrere MB groß ist ;)
>
Könnte vielleicht der MySQL-Proxy bei sowas helfen?
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
Martin Zemke
> Andreas Kretschmer schrieb:
>>> Die slow_query-Möglichkeit hilft mir relativ wenig, da das Logfile
>>> schnell mehrere MB groß ist ;)
>>
>> grep wurde auch für Dich erfunden.
>>
> Damit meinte ich, dass ich im slow-query-Log keine Unterscheidung
> zwischen den verschiedenen Gründen hab, warum es in dem Log drin steht.
Das wäre auch etwas zuviel verlangt. Das Slow-Query-Log enthält Queries
aus zwei möglichen Gründen:
1. die Query dauerte länger als das vorgegebene Zeitlimit
2. die Query wurde über einen Tablescan ausgeführt (mit
--log-queries-not-using-indexes)
Diese Bedingungen geben einen Hinweis, daß die Query (bzw. die
Tabellen-Struktur) verbesserungswürdig sind. Es sind aber problemlos
Fälle denkbar, wo eine Laufzeit von 10 Minuten oder ein Tablescan
vollkommen unbedenklich sind. Um das zu wissen, muß man aber über
zusätzliches Wissen verfügen, das MySQL nicht hat.
Auch die anderen genannten Kriterien sind keine harten "no-go"s:
Handler_read_rnd_next ... Lesen einer Row beim Tablescan
Qcache_lowmem_prunes ... Ergebnisse aus QC entfernt weil zu voll
Created_tmp_disk_tables ... tmp Table auf Disk angelegt
Select_range_check ... ein partieller Index-Scan
Select_full_join ... JOIN ohne JOIN-Bedingung
Die Vorgehensweise ist also, die Queries aus dem slow log erst mit dem
eigenen Verstand und wenn nötig mit EXPLAIN zu checken. Bekannte,
unbedenkliche Queries kann man z.B. mit einem SQL-Kommentar versehen
und dann von grep aus dem slow log werfen lassen.
XL