MySQL

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.

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.

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.

Read Replicas versprechen mehr Lesekapazität ohne größere Hardware, doch wer Leseanfragen blind auf Replicas verteilt, handelt sich veraltete Daten und schwer reproduzierbare Bugs ein. Erst ein bewusstes Read/Write-Splitting mit klarer Konsistenzstrategie macht MySQL Read Replicas zu einem verlässlichen Baustein der Skalierung.

Magento erlaubt mehrere Websites, Stores und Store-Views in einer einzigen Datenbank, doch mit wachsender Anzahl an Mandanten stellt sich die Frage, ob dieses Multi-Store-Schema noch trägt oder ob getrennte Datenbanken pro Mandant die bessere Architektur sind. Die Antwort haengt von Attributanzahl, Traffic-Verteilung und Team-Struktur ab, nicht von einer pauschalen Best Practice.

Eine einzelne offen gebliebene Transaktion kann den Undo-Log von InnoDB unkontrolliert wachsen lassen, Sperren über Minuten halten und Replikation verzögern, ohne dass eine einzige Fehlermeldung erscheint. Dieser Artikel erklärt, wie Long-Running Transactions in MySQL entstehen, wie man sie mit information_schema.innodb_trx zuverlässig aufspürt und mit welchen Timeout- und Batch-Strategien man sie im Anwendungscode von vornherein verhindert.