Latest revision as of 15:42, 12 August 2014

Notwendigkeit

Das obere Chart zeigt die MySQL CPU Last bei AWS RDS vor und nach der Optimierung.

Ansatz/Verfahren

Langlaufende Queries prüfen

netstat -lanp | grep :3306/mysql | wc -l

"netstat -lanp" listet alle Empfangsbereiten Sockets auf. Langsame Queries brauchen eine lange Verbindung zur Datenbank, ihr findet also die Verbindung zu DB hier. "grep :3306/mysql" filtert euch die Verbindungen zu einem mysql server heraus (je nach config mit dem Port oder dem namen). "wc -l" zählt die Verbindungen durch. Achtung, bei persistenten Verbindungen "schlafen" die Connections und werden auch ohne Nutzung nicht geschlossen.

Wenn ihr also den Verdacht habt, das Abfragen länger laufen als sie sollten, schaut ihr auf dem MySQL Server:

mysql -h{server} -u{user} -p{password} {database}

und gebt euch die Prozessliste aus:

mysql> show processlist;

Langlaufende Queries optimieren

In der Prozessliste könnt ihr zuschauen, welche Queries wie lange laufen. Bei der Laufzeit spricht man von "kosten". Lesen (SELECT) kostet sehr wenig, schreiben (UPDATE) viel. Ihr sucht also nach teuren Queries. Wenn SELECT Queries teuer sind, ist dies in der Regel ein Zeichen für einen falschen Index:

mysql> desc {tabellenname}

Auf den Daten die ihr per WHERE abfraget sollte ein Index liegen,

mysql> create index {feldname} on {tabellenname} ({feldname}) ;

wo ihr nicht auf die Idee kommen solltet, einfach auf alle Felder einen Index zu legen, das macht die Datenbank nur unnötig groß. Dazu jetzt mehr:

Tabellen optimieren

Auch wenn ihr viel Speicherplatz habt sollten die Felder nicht größer sein als nötig. Bei einer Datenbank verbraucht jedes Feld immer so viel Platz wie es konfiguriert ist. Wenn ihr ein CHAR(255) Feld für eine IP nutzte, speichert ihr pro Datensatz 239 Zeichen zu viel. So ist die Datenbank recht schnell zu groß um sie im Cache/Speicher zu halten.

mysql> alter table {tablename} modify {feldname} {typ}({groesse}), modify {feldname} {typ}({groesse});

That's it so far...