mysql index optimieren und reorganisieren

mysql index optimieren und reorganisieren

am 31.05.2006 09:35:07 von stephan.krebs

Hallo zusammen,

ich verwende bei einem Projekt mysql 4.018-nt.
Die DB wird per ASP/ASP.NET unter win 2003 Server genutzt.

Da sehr häufig Selects ausgeführt werden, dürfte die optimale
Indexierung der Tabellen einiges an Speed bringen.

Hierzu meine Fragen:
1 Gibt es ein Tool, dass z.B. 14 Tage lang den Datenbank-Traffic
beobachtet und dann eine Auswertung liefert, welche Felder wie
optimiert/indexiert werden sollten?

2 Gibt es die Möglichkeit ähnlich wie bei Access, dass die MySQL-DB
zB. alle 7 Tage sich reorganisiert

3 Ist es richtig, dass bei zu häufiger Indexierung von Feldern zwar
die Selects sehr schnell werden jedoch die Inserts und Updates umso
langsamer? Gibts da einen Tip.

4 Gibt es eine Anleitung anhand eines Beispiels im Web die einige von
den Fragen klärt?

Vielen Dank

Stefan

Re: mysql index optimieren und reorganisieren

am 31.05.2006 10:28:44 von Christian Kirsch

sk5678 schrieb:
> Hallo zusammen,
>
> ich verwende bei einem Projekt mysql 4.018-nt.
> Die DB wird per ASP/ASP.NET unter win 2003 Server genutzt.
>
> Da sehr häufig Selects ausgeführt werden, dürfte die optimale
> Indexierung der Tabellen einiges an Speed bringen.
>

*Gibt* es denn Performance-Probleme?

> Hierzu meine Fragen:
> 1. Gibt es ein Tool, dass z.B. 14 Tage lang den Datenbank-Traffic
> beobachtet und dann eine Auswertung liefert, welche Felder wie
> optimiert/indexiert werden sollten?
>

Spontan fällt mir nur der SlowQuery-Log ein. Und natürlich kannst Du
die häufig verwendeten SELECTs mal durch ein EXPLAIN laufen lassen und
Dir dessen Ausgabe angucken.


> 2. Gibt es die Möglichkeit ähnlich wie bei Access, dass die MySQL-DB
> z.B. alle 7 Tage sich reorganisiert
>

Gibt es die Möglichkeit, unter W2k3 Jobs zu einem vorher bestimmten
Zeitpunkt laufen zu lassen?

> 3. Ist es richtig, dass bei zu häufiger Indexierung von Feldern zwar
> die Selects sehr schnell werden jedoch die Inserts und Updates umso
> langsamer? Gibts da einen Tip.
>

Was meinst Du denn mit "häufige" Indizierung? Entweder auf dem Feld
*ist* ein Index, oder eben nicht. Und ja: Natürlich werden Inserts und
Updates langsamer, wenn viele Indizes verwendet werden. Außerdem
werden nicht "die" Selects sehr schnell, sondern nur die, die einen
Index auch verwenden (und dann möglichst noch den richtigen). Zu dem
Thema steht allerdings auch allerhand in der MySQL-Dokumentation unter
dev.mysql.com/doc - hast Du das gelesen?

> 4. Gibt es eine Anleitung anhand eines Beispiels im Web die einige von
> den Fragen klärt?

Weiß nicht. Glaubs nicht.

Re: mysql index optimieren und reorganisieren

am 31.05.2006 11:40:13 von Harald Stowasser

sk5678 schrieb:

> Hallo zusammen,
>
> ich verwende bei einem Projekt mysql 4.018-nt.
> Die DB wird per ASP/ASP.NET unter win 2003 Server genutzt.
>
> Da sehr häufig Selects ausgeführt werden, dürfte die optimale
> Indexierung der Tabellen einiges an Speed bringen.

Wer mysql 4.018-nt einsetzt macht sich normalerweise keine Gedanken um
Performance. ^^

> Hierzu meine Fragen:
> 1. Gibt es ein Tool, dass z.B. 14 Tage lang den Datenbank-Traffic
> beobachtet und dann eine Auswertung liefert, welche Felder wie
> optimiert/indexiert werden sollten?

Brain 1.0. ist auch hier wieder das beste Programm. Ich lasse davon
immer das mysql_slow.log parsen.
-> http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html

> 2. Gibt es die Möglichkeit ähnlich wie bei Access, dass die MySQL-DB
> z.B. alle 7 Tage sich reorganisiert

Ich denke du suchst so was wie:
http://dev.mysql.com/doc/refman/5.1/en/optimize-table.html

Mit myisamchk geht das selbe auch per Command. Das kannst du dann durch
den Scheduler aufrufen lassen.
http://dev.mysql.com/doc/refman/5.1/en/table-optimization.ht ml

> 3. Ist es richtig, dass bei zu häufiger Indexierung von Feldern zwar
> die Selects sehr schnell werden jedoch die Inserts und Updates umso
> langsamer?

Ja.

> Gibts da einen Tip.

*Meistens* gilt:
Lieber ein Index zu viel, als einer zu wenig. Was nicht heißen soll, das
du unnütze Indexe produzieren sollst.

Mach die Indexe deshalb nicht Pauschal (außer bei InnoDB[1]), sondern
guck dir bei den relevanten Querys den Explain an, und überlege Dir, ob
ein Index sinnvoll ist.
Brain 1.0 kann auch hier sehr nützlich sein.

Kombinierte Indexe wirken oft Wunder.

> 4. Gibt es eine Anleitung anhand eines Beispiels im Web die einige von
> den Fragen klärt?

Klar:
http://dev.mysql.com



[1] Für InnoDB *muss* für jeden Constraint ein Index vorhanden sein.