MySQL Optimierung

Post removed (X-No-Archive: yes)

Re: MySQL Optimierung

Bevor Du MySQL "optimieren" willst: gibt es dafür einen Grund? Läuft die
Datenbank zu langsam? Wenn ja: Hast Du in ihren Slow-Query-Log geguckt?

Wenn nein - warum willst Du dann irgendwas optimieren? Aus Deinem
Posting ging ja leider nichts faktisches hervor, nichtmal zur Größe der DB.

Re: MySQL Optimierung

Stefan Krohmer wrote:

> ich habe zur Zeit ein kleines Sorgenkind, das ich ein wenig tunen will. Es
> ist ein Fujitsu Siemens Primergy RX200S3-110DE mit 2 GB RAM. Auf ihm läuft
> MySQL 4.1, darin nur eine Datenbank (außer "mysql"), die auch gar keine
> allzu großen Einträge enthält (ok, ist sehr subjektiv, aber das soll
> vermutlich auch jetzt gar nicht das Problem sein). Ich habe mit Datenbank,
> Rechner, Webserver und Netzwerk ein paar unangenehme Sachen erlebt und will
> das ganze mal Stück für Stück durchputzen. Es läuft noch eine eigene
> Applikation darauf sowie Apache/PHP, sonst nichts zusätzliches als das, was
> Windows 2003 Server von Haus aus mitbringt.

Du läßt ein MySQL *produktiv* auf einem Windows laufen? Damit stehst du
ziemlich allein auf weiter Flur. Gibts dafür einen *guten* Grund?




> Daher würde ich mich
> freuen, wenn Ihr mir ein paar erste Tipps hättet
....

> Besten Dank, selbstverständlich auch für reine Links, wo ich weiter
> nachlesen kann (MySQL Doku habe ich schon in Arbeit ;-))!

Das Kapitel zur Optimierung im Handbuch ist Pflicht. Allgemeines Wissen
über Performancetuning sowieso. Und was ein Index ist, solltest du auch
wissen. Mehr kann man mangels Details erst mal nicht sagen.


XL

Re: MySQL Optimierung

Post removed (X-No-Archive: yes)

Re: MySQL Optimierung

Am 23.07.2007 21:49 schrieb Stefan Krohmer:
>
> Nach meinem Eindruck frisst sie für das, was sie leisten soll, recht viel
> Systemressourcen. Ich kann es gerade nicht genau beziffern, die genauen
> Daten liegen am Arbeitsplatz, aber ich bekomme von max. 5 Clients nahezu
> gleichzeitig einmal in der Sekunde Abfragen, wobei nur eine davon aus
> max. 5 Tabellen einige zig Datensätze liest, und es ist keine Join-
> Abfrage dabei, nur Selects.

Das alles hört sich eher nach "wenig" an.

> Es ist für mich etwas schwierig, das jetzt zu
> beschreiben und auch zu berechnen. Die Datenbank enthält knapp 30
> Tabellen, die verschiedene Objekte beschreiben, welche in C++ als Klassen
> angelegt sind.

Und dass es nicht MySQL sondern dein OR-Mapper (oder was immer) ist,
der die Ressourcen vertilgt, kann nicht sein? Was benutzt Du -
Hibernate? Oder bildest Du selbst brav alle Relationen in Klassen?

> Von diesen Objekten werden meistens max. 10 Stück gelesen.

Keine Vererbung? Keine "has a"-Beziehungen? Du kannst also sicher
sein, dass Deine 10 Objekte nicht jedes noch 10 weitere anziehen?

> Wenn zusätzlich noch eine Webserver Abfrage kommt, die aus ein paar der
> Tabellen ca. 100 Objekte liest, kommt es sogar gelegentlich vor, dass der
> Webserver die PHP Seite cancelt, weil sie länger als 30 Sekunden aufbaut
> (normalerweise 2 Sekunden, wenn sonst keine Abfragen laufen). Die
> längsten Einträge in den Tabellen enthalten deutlich weniger als 1000
> Bytes, und es sind max. 2000 Einträge in einer Tabelle.

Guck' Dir mal (wie Axel schon sagte) das MySQL-Handbuch
(dev.mysql.com/doc) an, dort den Abschnitt über Optimierung. Schalte
das Logging ein und guck' Dir an, welche Queries bei MySQL ankommen
(wer generiert die - wenn das eine OR-Abstraktionsschicht ist, lohnt
sich ein genauer Blick auf das, was da passiert).

Schick die Queries durch EXPLAIN (EXPLAIN SELECT ...) und guck' Dir
die Ausgabe an. Wenn da Full Table Scans auftauchen statt
Indexzugriffen, hast Du ein Problem.

Re: MySQL Optimierung

Christian Kirsch!

> Schick die Queries durch EXPLAIN (EXPLAIN SELECT ...) und guck' Dir
> die Ausgabe an. Wenn da Full Table Scans auftauchen statt
> Indexzugriffen, hast Du ein Problem.

Wobei man die full table scans mit --log-queries-not-using-indexes auch
ins slow query log bekommt.


Gruß
Daniel

Re: MySQL Optimierung

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

Re: MySQL Optimierung

Andreas Kretschmer wrote:
>>> Schick die Queries durch EXPLAIN (EXPLAIN SELECT ...) und guck' Dir
>>> die Ausgabe an. Wenn da Full Table Scans auftauchen statt
>>> Indexzugriffen, hast Du ein Problem.
>> Wobei man die full table scans mit --log-queries-not-using-indexes auch
>> ins slow query log bekommt.
> ... und nicht jeder full table scan per se schlecht ist.

Was genau der wunde Punkt bei dieser Logging-Option ist.

Ich haette da gerne nur Queries drin, die eigentlich - von ihrer Struktur -
von Indizes profitieren koennten und nicht einfach alle, bei denen keine
herangezogen werden.

Dass ein
SELECT foo FROM bar
keinen Index benutzen kann, weiss ich auch so, das muss mir nicht mein Log
vollrauschen.

Lustigerweise taucht obiger Query nicht im slow-log auf, wenn die
entsprechende Tabelle nur eine Zeile Inhalt hat.

Re: MySQL Optimierung

Am 24.07.2007 14:53 schrieb Sven Paulus:

> Dass ein
> SELECT foo FROM bar
> keinen Index benutzen kann, weiss ich auch so, das muss mir nicht mein Log
> vollrauschen.
>
> Lustigerweise taucht obiger Query nicht im slow-log auf, wenn die
> entsprechende Tabelle nur eine Zeile Inhalt hat.
>
Dann ist die Abfrage vermutlich auch nicht "slow" ;-)

--
Christian

Re: MySQL Optimierung

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

Re: MySQL Optimierung

Sven Paulus!

> Dass ein
> SELECT foo FROM bar
> keinen Index benutzen kann, weiss ich auch so, das muss mir nicht mein Log
> vollrauschen.

Oh, kann es nicht? :-)


mysql> create table bar (foo int);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into bar values (1),(2),(3);
Query OK, 3 rows affected (0.00 sec)
Records: 3 Duplicates: 0 Warnings: 0

mysql> explain extended select foo from bar;
+----+-------------+-------+------+---------------+------+-- -------+------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+------+-- -------+------+------+-------+
| 1 | SIMPLE | bar | ALL | NULL | NULL | NULL | NULL | 3 | |
+----+-------------+-------+------+---------------+------+-- -------+------+------+-------+
1 row in set, 1 warning (0.00 sec)

mysql> alter table bar add index (foo);
Query OK, 3 rows affected (0.00 sec)
Records: 3 Duplicates: 0 Warnings: 0

mysql> explain extended select foo from bar;
+----+-------------+-------+-------+---------------+------+- --------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+------+- --------+------+------+-------------+
| 1 | SIMPLE | bar | index | NULL | foo | 5 | NULL | 3 | Using index |
+----+-------------+-------+-------+---------------+------+- --------+------+------+-------------+
1 row in set, 1 warning (0.00 sec)


Gruß
Daniel

Re: MySQL Optimierung

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

Re: MySQL Optimierung

Andreas Kretschmer!

> An dieser Stelle könntest Du nun die table auch löschen und nur den
> Index behalten...

Bei der Beispieltabelle ist das langweilig, aber bei einer mit mehr
Spalten, bei der aber der Index auf die eine interessante im Speicher
gehalten wird, kann das schon eine Menge ausmachen :-)


Gruß
Daniel

Re: MySQL Optimierung

Post removed (X-No-Archive: yes)

Re: MySQL Optimierung

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)

Re: MySQL Optimierung

Sven Paulus wrote:
> Andreas Kretschmer wrote:

>>> Wobei man die full table scans mit --log-queries-not-using-indexes auch
>>> ins slow query log bekommt.
>
> Was genau der wunde Punkt bei dieser Logging-Option ist.
>
> Ich haette da gerne nur Queries drin, die eigentlich - von ihrer Struktur -
> von Indizes profitieren koennten und nicht einfach alle, bei denen keine
> herangezogen werden.

Das geht mit den normalen Einstellmöglichkeiten nicht. Aber bei Peter
Zaitzevs MySQLPerformanceBlog gibts einen Patch, der ein paar weitere
Möglichkeiten nachrüstet:

- Ausführungszeit und slow-Limit in Mikrosekunden.
- ein Limit für untersuchte Zeilen. Damit kann man Queries
unterdrücken, die nur wenige Zeilen scannen.

Ansonsten kannst du einen Kommentar in die Queries schreiben, bei
denen eine Optimierung nicht sinnvoll ist und sie später aus dem
Slow-Log rausfiltern.


XL