PHP / MySQL / Linux Stories

Ich habe bereits mehrfach mitbekommen, dass anscheinend kaum jemand weiß, dass man Indizes auch über mehrere Spalten anlegen kann.

Zuerst sollte erwähnt werden, dass MySQL im Normalfall pro Query nur EINEN pro Tabelle Index auf einmal nutzen kann (es gibt Ausnahmen, merged-index, aber nur unter bestimmten Umständen in bestimmten Queries).

Ein Beispiel für den Einsatz eines Index über mehrere Spalten, wäre z.B. das folgende:

(mehr…)

Ich beschäftige mich aus beruflichen Gründen schon recht lange mit der Thematik und möchte das gesammelte Wissen nun mal niederschreiben.

Es gibt definitiv keine Konfiguration, die allgemeingültig ist, aber ich versuche hiermit eine Hilfestellung zu geben, wie man die besten Werte für die eigenen Bedürfnisse findet.

Nicht nur der Server spielt eine Rolle, auch die Storage-Engine, um sich viel Stress zu ersparen, sollte man im vorraus planen, was man braucht und für welche Engine man sich entscheidet. Auch hier gibt es keine Universallösung, jede hat ihre Vor- und Nachteile, aber darauf will ich in diesem Eintrag nicht eingehen.

Da ich für das aktuell laufende Projekt nur InnoDB einsetze, beziehen sich die Ratschläge auf eine reine InnoDB Konfiguration und sollten ab MySQL Version 5.0 funktionieren.

(mehr…)

Die Meinungen, ob man komplette Objekte ablegen sollte oder nicht, gehen sehr auseinander.
Dagegen spricht zum Beispiel, dass man nicht mehr nach Inhalten in einem Objekt suchen kann oder immer der komplette Text neugeschrieben werden muss, auch wenn man nur eine Zahl ändert. Dafür spricht auch einiges, jedenfalls geht es mir darum, dass ich heute vor einem Problem stand.
(mehr…)

Konnte es selbst nicht glauben, aber ich war aus irgendeinem Grund sehr lange der Meinung, dass Queries mit “WHERE field = ‘value’” case-sensitiv sind und “WHERE LIKE ‘value’” nicht. Die Annahme ist komplett Falsch und es hängt alleine vom Charset (Collation) des Datenbankfeldes ab. Die meisten Standardcharset haben ein “_ci” am Ende ihres Namens, dies steht für “case-insensitive”. (mehr…)

Wenn möglich, sollte GROUP BY normalerweise verhindert werden. Es sorgt in (fast) jedem Fall für temp-Tables, die den Server unter Umständen recht schnell an seine Grenzen treiben (RAM, CPU). Oft kann man hier auf simple Subselects (oder Derived-Queries) zurückgreifen, um an die gewünschten Infos zu kommen.

Für den Fall, dass ein GROUP BY aber sein muss, das Ergebnis aber keiner Sortierung bedarf, sollte man ein ORDER BY NULL hinzufügen, da MySQL das grupperte Ergebnis sortiert, durch das Sortieren nach NULL, verhindert man dies und kann das Query unter Umständen noch beschleunigen.

SELECT a, COUNT(b) FROM test_table GROUP BY a ORDER BY NULL;

Hat man mehrere Slaves desselben Masterservers im Einsatz und will die Abfragen einigermaßen gleichmäßig verteilen (bzw. stärkeren Servern mehr Last zuweisen), muss man sich PHP-Technisch einen Weg einfallen lassen. Sicher, es gibt auch die Möglichkeit Hardwarebalancer zu nutzen, aber ich persönlich halte es für überflüssig zwei- bis viertausen Euro für so ein Gerät auszugeben. Folgender Code erledigt die Aufgabe für uns: (mehr…)

Beim analysieren der Auslastungen, der verschienden Server, viel uns auf, dass 2 unserer Datenbankserver, welche exakt die gleiche Aufgabe bei exakt gleicher Belastung, zwar in etwa die gleiche Load hatten, die CPU Last aber stark differierte.
(mehr…)

Die täglichen MySQL Backups sollte nicht mehr auf den Produktivservern geschehen, also wurde ein Dump-Server angeschafft, der die verschiedenen MySQL-Server (Master-Slave-Verbund + diverse “Hilfsserver”), einfach repliziert. Hier können dann täglich Dumps gezogen werden.

Das Problem, das auftrat und, meiner Meinung nach, nur schlecht Dokumentiert ist, ist das Betreiben von mehreren, unabhängigen MySQL Instanzen auf einerm Server. (mehr…)