Seite 5 - MySQL

Die vier Isolation Levels in MySQL klingen in der Dokumentation ähnlich, verhalten sich unter Last aber fundamental anders. Dieser Artikel erklärt READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ und SERIALIZABLE konkret in InnoDB, mit besonderem Fokus auf den Standard-Isolation-Level REPEATABLE READ und dessen Snapshot-basiertes Consistent-Read-Verhalten.

Wenn mehrere Nutzer gleichzeitig denselben Datensatz ändern, entscheidet die Wahl zwischen Optimistic Locking und Pessimistic Locking darüber, ob Ihre Anwendung Lost Updates zuverlässig verhindert oder unter Last in Wartezeiten stecken bleibt. Dieser Artikel erklärt beide Sperrstrategien in MySQL mit echtem SQL- und PHP-Code, zeigt SELECT FOR UPDATE und Versionsspalten im Detail und hilft bei der Entscheidung, welches Modell zu welchem Anwendungsfall passt.

Tausende gleichzeitige Anwendungsverbindungen überfordern MySQL schneller als die eigentliche Abfragelast. ProxySQL sitzt zwischen Anwendung und Datenbank, bündelt Verbindungen über Connection-Pooling und verteilt Lese- und Schreibzugriffe per Query-Routing-Regeln auf die passenden Server, ohne dass die Anwendung davon etwas merkt.

Wer InnoDB ohne bewusste Tablespace-Strategie betreibt, sammelt über Jahre einen unaufgeräumten system tablespace an, der nicht mehr schrumpft. innodb_file_per_table, OPTIMIZE TABLE und General Tablespaces geben die Kontrolle über Speicherplatz, Backup-Granularität und Wartungsfenster zurück, die im Standardbetrieb sonst verloren geht.

Ein Covering-Index enthält alle Spalten, die eine Abfrage benötigt, sodass der Server niemals die eigentliche Tabelle anfassen muss. Wer diese Technik gezielt einsetzt, verwandelt teure Random-I/O-Zugriffe auf die Tabelle in reine, sequenzielle Index-Only-Scans und spart damit oft mehr Zeit als jede zusätzliche Hardware.

Der native JSON-Typ erlaubt es, semi-strukturierte Daten direkt in MySQL zu speichern und mit JSON_EXTRACT sowie JSON_TABLE performant abzufragen. Ohne generierte Spalten für die Indizierung bleiben JSON-Abfragen jedoch langsam, und ohne klare Kriterien für den Einsatz verwandelt sich JSON schnell in eine Ausrede für fehlendes Schema-Design.

Wenn ein MySQL-Server mitten in einem Schreibvorgang abstürzt, entscheidet das Redo Log darüber, ob Daten verloren gehen oder ob die Datenbank sich beim nächsten Start automatisch selbst repariert. Das Verständnis von Write-Ahead Logging, Checkpoint-Mechanik und Log-Sizing ist deshalb keine akademische Übung, sondern die Grundlage für belastbare Produktionsdatenbanken. Dieser Artikel erklärt den kompletten Mechanismus mit echten Konfigurationsbeispielen.

Partitionierung verspricht schnellere Löschvorgänge und bessere Wartbarkeit bei sehr grossen Tabellen, ist aber kein universelles Performance-Werkzeug. RANGE-, LIST- und HASH-Partitionierung lösen unterschiedliche Probleme und bringen eigene Einschränkungen bei Fremdschlüsseln, Unique Keys und der Query-Planung mit, die vor dem Einsatz bekannt sein müssen.

Ein MySQL Failover, der im Ernstfall Daten verliert oder die Anwendung minutenlang blockiert, ist kein Sicherheitsnetz, sondern ein zusätzliches Risiko. Wer geplanten von ungeplantem Failover unterscheidet, GTID konsequent nutzt und Failover regelmäßig testet, verwandelt einen abstrakten Notfallplan in einen verlässlichen operativen Prozess.

Der Slow Query Log ist nur der erste Schritt, denn eine Rohdatei mit tausenden Zeilen bringt allein keine Erkenntnis. Dieser Artikel zeigt, wie long_query_time sinnvoll gewählt wird, wie pt-query-digest und mysqldumpslow die Daten aggregieren, und wie man daraus eine belastbare Priorisierung für die nächsten Optimierungen ableitet.