MySQL

Semi-synchrone Replikation garantiert, dass ein Replica eine Transaktion empfangen hat, bevor der Source den Commit bestätigt. Sie garantiert aber ausdrücklich nicht, dass diese Transaktion auf dem Replica bereits angewendet wurde. Wer diese beiden Größen im Monitoring verwechselt, hält einen Replica für aktuell, der in Wirklichkeit deutlich hinterherhinkt.

Ein tägliches Backup allein rettet nur den Stand von Mitternacht. Point-in-Time Recovery kombiniert ein Basis-Backup mit dem gezielten Replay von Binlogs und stellt eine MySQL-Datenbank bis zur letzten korrekten Transaktion wieder her, direkt vor einem fehlerhaften DELETE oder DROP.

CPU-Auslastung und freier Speicher allein sagen fast nichts über die tatsächliche Gesundheit einer MySQL-Datenbank aus. Erst Buffer Pool Hit Ratio, Connection-Sättigung, Replikationslag und Lock Waits zusammen zeigen, ob ein System stabil läuft oder kurz vor einem Vorfall steht, den klassisches Server-Monitoring gar nicht sieht.

Prepared Statements werden oft nur als Schutz vor SQL-Injection verstanden, sind aber gleichzeitig ein Performance-Werkzeug für wiederholt ausgeführte Abfragen. Dieser Artikel erklärt, warum String-Concatenation strukturell unsicher ist, wie Prepared Statements dieses Problem lösen, was der Unterschied zwischen Server-Side und Client-Side Prepare ist, und zeigt korrekte Implementierungen mit PDO und mysqli inklusive typischer Fallstricke.

Der Zeichensatz utf8 in MySQL ist eine historische Falle, die maximal drei Byte pro Zeichen erlaubt und damit Emoji sowie viele seltene Schriftzeichen stillschweigend verwirft oder Fehler wirft. utf8mb4 bildet echtes Unicode vollständig ab, verlangt aber die richtige Collation-Wahl und eine sauber geplante Migration, um Indexlängen und Sortierreihenfolgen nicht zu brechen.

Log-Tabellen wie report_event, customer_visitor und catalog_compare_item protokollieren Besucherverhalten und wachsen bei jedem Seitenaufruf, oft schneller als jede andere Tabellengruppe im Shop. Wer das eingebaute Log Cleaning richtig konfiguriert und für Tabellen ohne automatische Bereinigung eigene Skripte baut, hält die Datenbank schlank, ohne auf wichtige Reporting-Daten zu verzichten.

Nicht jeder Replica braucht den kompletten Datenbestand des Sources. Replikationsfilter erlauben es, Reporting-Replicas ohne sensible Kundendaten oder Multi-Store-Setups mit sauber getrennten Datenbanken aufzubauen, bringen aber eigene Fallstricke mit, sobald ein Filter nachträglich verändert werden muss.

InnoDB gilt als Row-Level-Locking-Engine, trotzdem entstehen in der Praxis regelmäßig Table Locks, etwa bei ALTER TABLE oder explizitem LOCK TABLES. Dieser Artikel erklärt, wie InnoDB Row Locks technisch umsetzt, wann Table-Locking unvermeidlich ist, und wie die Lock-Modi S, X, IS und IX als Intention Locks zusammenspielen.

InnoDB Cluster bündelt Group Replication, die AdminAPI der MySQL Shell und MySQL Router zu einer integrierten Lösung, die Hochverfügbarkeit ohne zusätzliche Drittwerkzeuge bereitstellt. Wer bereits manuell mit Group Replication gearbeitet hat, erkennt schnell, wie viel operative Komplexität die AdminAPI tatsächlich abnimmt, und wo die Grenzen dieser Automatisierung liegen.

EXPLAIN zeigt, was der Optimizer plant, EXPLAIN ANALYZE zeigt, was tatsächlich passiert ist. Wer type, key, rows und Extra korrekt interpretiert und die geschätzten Zeilen mit den echten Ausführungsstatistiken vergleicht, findet Volltabellenscans und Filesorts, bevor sie in Produktion zum Problem werden.