MySQL-Experten anwesend? ;-)

Hallo Gruppe,

folgende Bitte: Ich habe hier einen dedizierten MySQL-Server, der
durchaus ein wenig schneller laufen könnte ;-) Da MySQL eine Flut an
Parametern bietet, die zumindest ich nicht durchschaue, möchte ich die
sehr geehrte Leserschaft um ihre Mithilfe bitten.

Ich habe mal ein paar Informationen zusammengestellt:

Hardware:
Dual P4 2,8 GHz
4 GB RAM

http://ksau.de/mysql/runtime_information.pdf
http://ksau.de/mysql/variables.pdf
http://ksau.de/mysql/memory_usage.png

Jede Anregung ist willkommen!

Insbesondere interessiert mich: Werden die 4GB sinnvoll eingesetzt? Ein
Großteil wird anscheinend für Plattencache benutzt. Ist es nicht
eventuell sinnvoller, MySQL für applikationseigene Buffer mehr
Arbeitsspeicher zuzuweisen?

Gruß und Dank!
Keith Sauvant

Re: MySQL-Experten anwesend? ;-)

On 2006-12-06 Keith Sauvant wrote:
> Hallo Gruppe,
>=20
> folgende Bitte: Ich habe hier einen dedizierten MySQL-Server, der=20
> durchaus ein wenig schneller laufen könnte ;-) Da MySQL eine Flut an=20
> Parametern bietet, die zumindest ich nicht durchschaue, möchte ich die=
=20
> sehr geehrte Leserschaft um ihre Mithilfe bitten.

Schau mal hier: http://en.wikibooks.org/wiki/MySQL/Optimization

tschüss,

-christian-

Re: MySQL-Experten anwesend? ;-)

Hi Keith

Keith Sauvant wrote:
> folgende Bitte: Ich habe hier einen dedizierten MySQL-Server, der
> durchaus ein wenig schneller laufen könnte ;-) Da MySQL eine Flut an
> Parametern bietet, die zumindest ich nicht durchschaue, möchte ich die
> sehr geehrte Leserschaft um ihre Mithilfe bitten.
[...]

Die Frage lautet bei Optimierungen immer, was denn spezifisch gemacht
werden muss. Sprich, was sind so die Applikationen, die schneller werden
sollen?

> Insbesondere interessiert mich: Werden die 4GB sinnvoll eingesetzt? Ein
> Großteil wird anscheinend für Plattencache benutzt. Ist es nicht
> eventuell sinnvoller, MySQL für applikationseigene Buffer mehr
> Arbeitsspeicher zuzuweisen?

MySQL nimmt sich so viel RAM wie es benötigt. 4 GB sollten für alles
mögliche reichen. :-)

Wie immer: Schlecht programmierte Applikationen können jede noch so
krasse Maschine auslasten. Sie zu optimieren bringt meistens um
Grössenordnungen mehr als an der HW oder an Parametern rumzuschrauben.

HTH, Johannes

Re: MySQL-Experten anwesend? ;-)

Johannes Vogel wrote:
> Keith Sauvant wrote:
>
>> Insbesondere interessiert mich: Werden die 4GB sinnvoll eingesetzt? Ein
>> Großteil wird anscheinend für Plattencache benutzt. Ist es nicht
>> eventuell sinnvoller, MySQL für applikationseigene Buffer mehr
>> Arbeitsspeicher zuzuweisen?
>
> MySQL nimmt sich so viel RAM wie es benötigt.

Nur im Rahmen der Limits, die der Admin MySQL gesetzt hat. Wenn z.B.
in my.cnf key_buffer_size=64MB gesetzt ist, dann wird MySQL auch nicht
mehr verwenden, auch wenn es eigentlich sinnvoll wäre.


XL

Re: MySQL-Experten anwesend? ;-)

Keith Sauvant wrote:
> Hallo Gruppe,
>
> folgende Bitte: Ich habe hier einen dedizierten MySQL-Server, der
> durchaus ein wenig schneller laufen könnte ;-) Da MySQL eine Flut an
> Parametern bietet, die zumindest ich nicht durchschaue, möchte ich die
> sehr geehrte Leserschaft um ihre Mithilfe bitten.
>
> Ich habe mal ein paar Informationen zusammengestellt:
>
> Hardware:
> Dual P4 2,8 GHz
> 4 GB RAM
>
> http://ksau.de/mysql/runtime_information.pdf
> http://ksau.de/mysql/variables.pdf

Das kann man auch (besser lesbar) als Text bekommen.
Ich sehe schon: das ist eine PHP-Applikation :-)

> http://ksau.de/mysql/memory_usage.png

Welches Tool hat das erzeugt?


> Jede Anregung ist willkommen!

1. Anscheinend verwendest du ausschließlich MyISAM-Tabellen. Dann
solltest du alle anderen Storage Engines deaktivieren, per
skip-$ENGINE in my.cnf.

2. Der key_buffer (MyISAM Index-Cache) scheint mit 400MB groß genug
zu sein; zumindest die Trefferrate (key_read_requests:key_reads)
ist bei ca. 1000:1 jenseits von gut und böse.

3. Für den Query-Cache kann man das leider nicht sagen. Du hast 21 Mio
Inserts aber nur 15 Mio Hits. Noch dazu führten 13 Mio der Inserts
zu einem "lowmem-prune" - sprich es wurden Einträge aus dem Cache
geworfen, weil kein Platz mehr war. Entweder machst du diesen Cache
deutlich größer oder du cachst nur Queries, für die es eine reali-
stische Chance der Wiederverwendung gibt. Oder ganz abschalten.

4. Der table_cache ist voll ausgenutzt. Etwas mehr kann hier nicht
schaden - wird aber auch nicht viel bringen.

5. Es werden tmp_tables angelegt, knapp 0.1% davon auf der Platte.
Es besteht eine gewisse Wahrscheinlichkeit, daß das ORDER BY sind,
für die der sort_buffer zu klein war. Ich würde an deiner Stelle
den sort_buffer vergrößern und das weiter beobachten.

6. Du hast eine Menge Zugriffe über Handler_read_rnd_next - aka
Tablescans. Du solltest die entsprechenden Queries finden und
Queries/Indexe optimieren. Laß ein slow-querly Log schreiben
und analysiere die Queries, die da reinkommen.


XL

Re: MySQL-Experten anwesend? ;-)

Hallo,

Keith Sauvant wrote:
>
> Insbesondere interessiert mich: Werden die 4GB sinnvoll eingesetzt?

Unterstützt dein Betriebssystem die 4 GB Ram?


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: MySQL-Experten anwesend? ;-)

Hallo Keith,

> Jede Anregung ist willkommen!

auch von nicht-Experten?

> Insbesondere interessiert mich: Werden die 4GB sinnvoll eingesetzt? Ein
> Großteil wird anscheinend für Plattencache benutzt. Ist es nicht eventuell
> sinnvoller, MySQL für applikationseigene Buffer mehr Arbeitsspeicher
> zuzuweisen?

http://dev.mysql.com/doc/refman/5.0/en/myisam-key-cache.html

"For data blocks, MySQL uses no special cache. Instead it relies on the
native operating system filesystem cache."

Also alles wunderbar :-))

Schöne Grüße,
Oliver

Re: MySQL-Experten anwesend? ;-)

Keith Sauvant schrieb:

> Jede Anregung ist willkommen!

Ich würde bei der Last doch empfehlen, einen externen Berater dazu zu
holen. Die Ursache für "ist nicht schnell genug" kann an so vielen
Stellen zu finden sein, dass man das kaum per Ferndiagnose gelöst
bekommt. Zumal erfahrungsgemäß erhebliche Performacereserven auch auf
der Applikationsseite zu finden sind.

Gruß, Marcel

Re: MySQL-Experten anwesend? ;-)

Hallo Axel,

> Das kann man auch (besser lesbar) als Text bekommen.
> Ich sehe schon: das ist eine PHP-Applikation :-)

Höre ich da einen leisen Unterton raus? ;-)

>> http://ksau.de/mysql/memory_usage.png
> Welches Tool hat das erzeugt?

http://munin.projects.linpro.no/
Kann ich sehr empfehlen.

> 1. Anscheinend verwendest du ausschließlich MyISAM-Tabellen. Dann
> solltest du alle anderen Storage Engines deaktivieren, per
> skip-$ENGINE in my.cnf.

ok

> 2. Der key_buffer (MyISAM Index-Cache) scheint mit 400MB groß genug
> zu sein; zumindest die Trefferrate (key_read_requests:key_reads)
> ist bei ca. 1000:1 jenseits von gut und böse.

wenigstens etwas...

> 3. Für den Query-Cache kann man das leider nicht sagen. Du hast 21 Mio
> Inserts aber nur 15 Mio Hits. Noch dazu führten 13 Mio der Inserts
> zu einem "lowmem-prune" - sprich es wurden Einträge aus dem Cache
> geworfen, weil kein Platz mehr war. Entweder machst du diesen Cache
> deutlich größer oder du cachst nur Queries, für die es eine reali-
> stische Chance der Wiederverwendung gibt. Oder ganz abschalten.

Ganz abschalten halte ich nicht für sinnvoll, das Ding hat bei uns
durchaus seine Berechtigung. Eine typische Nutzerinteraktion setzt sich
aus vielen kleinen (zum Beispiel Bezeichner-lookup in sprachbahängiger
Tabelle) und wenigen grossen bis sehr grossen Queries zusammen. Auch die
grossen sind durchaus wiederverwendbar und sollten sinnvollerweise
gecached werden. Ich habe ein bisschen Angst, den cache noch grösser zu
machen, weil dann die Verwaltung desselben eventuell die Vorteile wieder
auffrisst... Gibts dazu hier Erfahrungswerte?

> 4. Der table_cache ist voll ausgenutzt. Etwas mehr kann hier nicht
> schaden - wird aber auch nicht viel bringen.

ok

> 5. Es werden tmp_tables angelegt, knapp 0.1% davon auf der Platte.
> Es besteht eine gewisse Wahrscheinlichkeit, daß das ORDER BY sind,
> für die der sort_buffer zu klein war. Ich würde an deiner Stelle
> den sort_buffer vergrößern und das weiter beobachten.

Werden wir versuchen

> 6. Du hast eine Menge Zugriffe über Handler_read_rnd_next - aka
> Tablescans. Du solltest die entsprechenden Queries finden und
> Queries/Indexe optimieren. Laß ein slow-querly Log schreiben
> und analysiere die Queries, die da reinkommen.

Haben wir schon mehrfach getan und tun wir laufend. Ich fürchte
applikationsseitig sind zumindest die Klassiker ziemlich ausgereizt.
Deshalb eben jetzt mal die Datenbank beschuldigen ;-)

Danke für Deine ausführliche Antwort, genau so hatte ich mir das
vorgestellt ;-)

Gruss
Keith

Re: MySQL-Experten anwesend? ;-)

> Unterstützt dein Betriebssystem die 4 GB Ram?

Oh ja. Daran liegts leider nicht.

Re: MySQL-Experten anwesend? ;-)

>> Jede Anregung ist willkommen!
> auch von nicht-Experten?

Das ist ja immer relativ ;-)

> "For data blocks, MySQL uses no special cache. Instead it relies on the
> native operating system filesystem cache."
>
> Also alles wunderbar :-))

Nene, ist ja zu langsam ;-) Aber danke, hatte ich auch schon gelesen.
Trotzdem könnte ich mir vorstellen, das MySQL durchaus mehr davon
profitiert, wenn das ein oder andere bit dediziert für Sonderaufgaben
reserviert wird...

Re: MySQL-Experten anwesend? ;-)

>> Jede Anregung ist willkommen!
>
> Ich würde bei der Last doch empfehlen, einen externen Berater dazu zu
> holen. Die Ursache für "ist nicht schnell genug" kann an so vielen
> Stellen zu finden sein, dass man das kaum per Ferndiagnose gelöst
> bekommt. Zumal erfahrungsgemäß erhebliche Performacereserven auch auf
> der Applikationsseite zu finden sind.

Wolltest Du Dich damit anbieten? ;-) Ich habe vor ein paar Monaten genau
das versucht: Von MySQL einen Berater ins Haus zu bekommen. Die
vertriebliche Reaktion darauf war allerdings SO unbefriedigend, dass ich
das damals ganz schnell wieder verworfen habe. Vielleicht versuch ichs
einfach nochmal...

Allerdings habe ich auch Hilfestellungen aus der Community sehr zu
schätzen gelernt. Und das hier ist wieder ein gutes Beispiel: Einfach
nett gefragt und die Resonanz macht Spaß.

Danke dafür!
Keith

Re: MySQL-Experten anwesend? ;-)

Keith Sauvant schrieb:

> folgende Bitte: Ich habe hier einen dedizierten MySQL-Server, der
> durchaus ein wenig schneller laufen könnte ;-) Da MySQL eine Flut an
> Parametern bietet, die zumindest ich nicht durchschaue, möchte ich die
> sehr geehrte Leserschaft um ihre Mithilfe bitten.

Die durchschaue ich auch nicht wirklich :-)

Je länger ich mir diesen Thread jedoch anschaue, desto mehr keimt in mir
der Verdacht auf, dass das Problem nicht am Server, sondern eher an den
Tabellenstrukturen liegt. Insbesondere die Indizes (oder Indexe für die
Germanophoben unter uns) Deiner Tabellen solltest Du mal überprüfen.

EXPLAIN sollte Dir dabei behiflich sein können.

Gruß. Claus
--
,~°O O
O ,´ / |/|\
/ |¯`. Das neue Hochzeits-Branchenbuch im Internet ,´ / | |\
/__| `~...............................................~´ /___|/ /

Re: MySQL-Experten anwesend? ;-)

Hallo Claus,

> Je länger ich mir diesen Thread jedoch anschaue, desto mehr keimt in
> mir der Verdacht auf, dass das Problem nicht am Server, sondern eher
> an den Tabellenstrukturen liegt. Insbesondere die Indizes (oder
> Indexe für die Germanophoben unter uns) Deiner Tabellen solltest Du
> mal überprüfen. EXPLAIN sollte Dir dabei behiflich sein können.

Ich darf mich da zitieren:
> Ich fürchte applikationsseitig sind zumindest die Klassiker ziemlich
> ausgereizt.

Lass mich noch zwei Punkte anfügen:

- Ich beschäftige mich seit vielen Jahren mit Datenbankdesign. Auch wenn
man mit solchen Aussagen SEHR vorsichtig sein sollte ;-) bin ich davon
überzeugt, zumindest 90% des applikationsseitigen Optimierungspotentials
ausgenutzt zu haben. Was nicht heisst, das wir nicht weiter danach suchen...

- Selbst wenn die Applikation noch hier und da Potential bietet, sollte
mich das doch nicht daran hindern, auch datenbankseitig alle
Möglichkeiten auszuschöpfen. Wenn ich durch simples "Drehen" an
Parameter x eine Beschleunigung erreiche - warum nicht?

Gruß
Keith

Re: MySQL-Experten anwesend? ;-)

Keith Sauvant wrote:
> Hallo Axel,
>
>> 3. Für den Query-Cache kann man das leider nicht sagen. Du hast 21 Mio
>> Inserts aber nur 15 Mio Hits. Noch dazu führten 13 Mio der Inserts
>> zu einem "lowmem-prune" - sprich es wurden Einträge aus dem Cache
>> geworfen, weil kein Platz mehr war. Entweder machst du diesen Cache
>> deutlich größer oder du cachst nur Queries, für die es eine reali-
>> stische Chance der Wiederverwendung gibt. Oder ganz abschalten.
>
> Ganz abschalten halte ich nicht für sinnvoll, das Ding hat bei uns
> durchaus seine Berechtigung. Eine typische Nutzerinteraktion setzt sich
> aus vielen kleinen (zum Beispiel Bezeichner-lookup in sprachbahängiger
> Tabelle) und wenigen grossen bis sehr grossen Queries zusammen. Auch die
> grossen sind durchaus wiederverwendbar und sollten sinnvollerweise
> gecached werden. Ich habe ein bisschen Angst, den cache noch grösser zu
> machen, weil dann die Verwaltung desselben eventuell die Vorteile wieder
> auffrisst... Gibts dazu hier Erfahrungswerte?

Die Effizienz des Query-Caches läßt sich von Weitem oder im Voraus
schlecht abschätzen. Der Cache ist zwar im Trefferfall sehr flott,
weil die Query ja nicht mal zum SQL-Parser muß. Aber Cache-Inserts
sind nicht umsonst und auch alle Schreibzugriffe müssen den Cache
checken, um veraltete Cache-Einträge zu invalidieren.

Außerdem nutzt der Query-Cache ein sehr einfaches Invalidierungs-
Schema: sobald eine Tabelle geändert wird, werden alle Ergebnisse,
deren Query irgendwie mit dieser Tabelle zu tun hat, aus dem Cache
geworfen.

Auch scheint deine Anwendung nicht sehr Cache-freundlich zu sein.
Du hast:

2 Mio DELETEs
+ 12 Mio INSERTs
+ 21 Mio UPDATEs
= 35 Mio Schreibzugriffe

22 Mio SELECTs
+ 15 Mio QCache-Hits (also auch SELECT)
= 37 Mio Lesezugriffe

Daß es bei solchen Verhältnissen überhaupt zu Cache-Hits kommt,
kann nur bedeuten, daß Schreib-/Lesezugriffe auf verschiedenen
Hotspots stattfinden. Leider geben die MySQL-Statistiken das nicht
her, aber wenn du herausfindest, welche Tabellen das beste Lese-
zu-Schreibverhältnis haben, dann solltest du erstmal nur Queries
auf diese Tabellen durch den Query-Cache schicken.

Was natürlich immer geht, sind applikationsseitige Caches, die dann
auch keine Rücksicht auf die "richtigen" Daten nehmen, sondern den
Cache-Inhalt nach einer festen Zeit invalidieren. Kommt aber auf
die Anwendung an, ob das erlaubt ist. Ein gängiger Zwischenweg sind
sessionbasierte Caches, die bspw. ein Suchergebnis in der Nutzer-
session cachen.

>> 6. Du hast eine Menge Zugriffe über Handler_read_rnd_next - aka
>> Tablescans. Du solltest die entsprechenden Queries finden und
>> Queries/Indexe optimieren. Laß ein slow-querly Log schreiben
>> und analysiere die Queries, die da reinkommen.
>
> Haben wir schon mehrfach getan und tun wir laufend. Ich fürchte
> applikationsseitig sind zumindest die Klassiker ziemlich ausgereizt.

Das Default-Laufzeit-Limit von 10 Sekunden bevor eine Query als
"slow" angesehen wird, ist IMHO etwas hoch. Gerade bei Webanwen-
dungen würde ich das eher bei 2-3 Sekunden sehen. Die nützliche
Option, Queries loggen zu lassen, die keinen Index verwenden, hat
dein etwas angestaubtes 4.0.x leider noch nicht.

Trotzdem ist dieser Weg der erfolgversprechendste. Reorganisation
von Daten (schreib-intensive und lese-intensive Daten trennen),
Vorverarbeitung, evtl. redundante Datenhaltung - das Repertoire
ist hier riesig.


XL

Re: MySQL-Experten anwesend? ;-)

Keith Sauvant wrote:
>>
>> Ich würde bei der Last doch empfehlen, einen externen Berater dazu zu
>> holen. Die Ursache für "ist nicht schnell genug" kann an so vielen
>> Stellen zu finden sein, dass man das kaum per Ferndiagnose gelöst
>> bekommt. Zumal erfahrungsgemäß erhebliche Performacereserven auch auf
>> der Applikationsseite zu finden sind.
>
> Wolltest Du Dich damit anbieten? ;-) Ich habe vor ein paar Monaten genau
> das versucht: Von MySQL einen Berater ins Haus zu bekommen. Die
> vertriebliche Reaktion darauf war allerdings SO unbefriedigend, dass ich
> das damals ganz schnell wieder verworfen habe. Vielleicht versuch ichs
> einfach nochmal...

Versuch es! Ich weiß auch von wenigstens einem MySQL-Consultant,
der ab und zu hier reinschaut. Notfalls könnte ich dir auch einen
etwas direkteren Kontakt vermitteln ;-)


XL

Re: MySQL-Experten anwesend? ;-)

Keith Sauvant wrote:
> Ich habe mal ein paar Informationen zusammengestellt:

Dein MySQL ist zu alt (4.0.x).
Dein key_buffer_size ist recht klein (der Datenbankserver kann für
MyISAM-Tabellen bis zu 50% des Speichers belegen, also bei Dir ca. 2 GB),
aber die key_read_requests/key_reads Trefferrate ist groß genug.
Deine Indices sind schlecht, Du hast einige hundertausend Full Joins auf 22
Mio Select-Queries. Mit mehr Indices wirst Du auch mehr key_buffer brauchen.

Weitere Serverparameter können korrigiert werden.

MySQL Consulting kannst Du über Hana Hütter (hana@mysql.de) bekommen.

Kris

Re: MySQL-Experten anwesend? ;-)

Hallo Kristian,

Kristian Köhntopp schrieb:
> Dein MySQL ist zu alt (4.0.x)

Ist SLES9 (Kundenwunsch), lässt sich also nicht ohne weiteres ändern.

> Dein key_buffer_size ist recht klein (der Datenbankserver kann für
> MyISAM-Tabellen bis zu 50% des Speichers belegen, also bei Dir ca. 2
> GB), aber die key_read_requests/key_reads Trefferrate ist groß genug.
>
ok

> Deine Indices sind schlecht, Du hast einige hundertausend Full Joins
> auf 22 Mio Select-Queries. Mit mehr Indices wirst Du auch mehr
> key_buffer brauchen.

Werde ich mir daraufhin nochmal ansehen.

Axel Schwenke schrieb:
> Die nützliche Option, Queries loggen zu lassen, die keinen Index
> verwenden, hat dein etwas angestaubtes 4.0.x leider noch nicht.

Vielleicht mal damit, gute Anregung.

Gruß und Dank
Keith

Re: MySQL-Experten anwesend? ;-)

Hi Axel,

> Auch scheint deine Anwendung nicht sehr Cache-freundlich zu sein. Du
> hast:
>
> 2 Mio DELETEs + 12 Mio INSERTs + 21 Mio UPDATEs = 35 Mio
> Schreibzugriffe
>
> 22 Mio SELECTs + 15 Mio QCache-Hits (also auch SELECT) = 37 Mio
> Lesezugriffe

Das täuscht: Ich habe periodisch sehr viele Schreibzugriffe, dazwischen
aber lange Phasen relativer Schreibruhe, da kann sich dann de Cache
austoben.

> Daß es bei solchen Verhältnissen überhaupt zu Cache-Hits kommt, kann
> nur bedeuten, daß Schreib-/Lesezugriffe auf verschiedenen Hotspots
> stattfinden.

Oder zeitlich nicht gleich verteilte Vorgänge, s.o.

> Was natürlich immer geht, sind applikationsseitige Caches, die dann
> auch keine Rücksicht auf die "richtigen" Daten nehmen, sondern den
> Cache-Inhalt nach einer festen Zeit invalidieren. Kommt aber auf die
> Anwendung an, ob das erlaubt ist. Ein gängiger Zwischenweg sind
> sessionbasierte Caches, die bspw. ein Suchergebnis in der Nutzer-
> session cachen.

Auch das tun wir bereits. Temporärtabellen nehmen das fertig
zusammengejointe Ergebnis auf. Änderungen der "Basistabelle" werden auch
in der Temporärtabelle sofort sichtbar, Änderungen der referenzierten
Tabellen erst nach (zyklischem) refresh.

> Das Default-Laufzeit-Limit von 10 Sekunden bevor eine Query als
> "slow" angesehen wird, ist IMHO etwas hoch. Gerade bei Webanwen-
> dungen würde ich das eher bei 2-3 Sekunden sehen.

Die Anwendung ist nicht unbedingt eine typische Webanwendung. Queries
mit Laufzeiten im Minutenbereich sind durchaus der Regelfall. Und nein -
da fehlt (meistens) kein Index ;-)

> Die nützliche Option, Queries loggen zu lassen, die keinen Index
> verwenden, hat dein etwas angestaubtes 4.0.x leider noch nicht.

Kannte ich noch nicht, werden wir auf den Entwicklungsmaschinen
aktivieren und auswerten.

Danke again
Keith

Re: MySQL-Experten anwesend? ;-)

Keith Sauvant schrieb:
> Axel Schwenke schrieb:
>> Die nützliche Option, Queries loggen zu lassen, die keinen Index
>> verwenden, hat dein etwas angestaubtes 4.0.x leider noch nicht.

falls das nicht slow_query_log wäre ... könnt ihr mir mal auf d=
ie=20
Sprünge helfen?

Werner

Re: MySQL-Experten anwesend? ;-)

werner bauer wrote:
> Keith Sauvant schrieb:
>> Axel Schwenke schrieb:

>>> Die nützliche Option, Queries loggen zu lassen, die keinen Index
>>> verwenden, hat dein etwas angestaubtes 4.0.x leider noch nicht.
>
> falls das nicht slow_query_log wäre ... könnt ihr mir mal auf
> die Sprünge helfen?

--log-queries-not-using-indexes

ist eine zusätzliche Option, wenn man --log-slow schon benutzt. Dann
werden alle Queries, die keinen Index benutzen, ins slow-log geloggt.
Unabhängig davon, wie lange sie brauchen. Gibts aber erst ab 5.0


XL