Seite 2 - MySQL

Wer Transaktionen in MySQL nur als Syntax versteht, ohne zu wissen was InnoDB im Hintergrund tut, riskiert inkonsistente Daten unter Last. Dieser Artikel zeigt, wie START TRANSACTION, COMMIT und ROLLBACK konkret wirken, wie Autocommit den Alltag beeinflusst, und wie InnoDB jede einzelne ACID-Eigenschaft technisch garantiert, von Undo Log bis Redo Log.

MySQL-Replikation entscheidet darüber, wie viele Transaktionen im Fehlerfall verloren gehen können und wie stark eine Anwendung auf veraltete Lesedaten trifft. Wer den Unterschied zwischen asynchroner und semi-synchroner Replikation, Binlog-Verarbeitung und Replication Lag versteht, kann die Konfiguration gezielt auf Konsistenzanforderungen statt auf Standardwerte auslegen.

Ein regelmaessiger Datenbank-Healthcheck deckt Probleme auf, bevor sie zu Ausfaellen im Checkout fuehren: falsch dimensionierter Buffer Pool, unentdeckte Slow Queries, wachsender Replikationslag, fragmentierte Tabellen und ungetestete Backups sind die haeufigsten stillen Risiken in Magento-Datenbanken. Diese Checkliste buendelt alle relevanten Pruefpunkte in einem wiederholbaren Workflow.

Magento-Datenbanken wachsen selten durch Produktdaten, sondern durch Logs, verwaiste Warenkörbe und URL-Rewrites, die niemand aktiv löscht. Wer die üblichen Verdächtigen kennt, Tabellengrößen regelmäßig misst und eine wiederholbare Bereinigungsroutine etabliert, verhindert, dass Backups, Deployments und Reindex-Läufe unter dem Datenbank-Wachstum leiden.

Eine InnoDB-Page ist größer als der atomare Schreibblock der meisten Speichersysteme, wodurch ein Stromausfall mitten im Schreibvorgang eine Page halb alt und halb neu zurücklassen kann. Der Doublewrite Buffer ist der Mechanismus, der genau dieses Szenario, den Torn Page, zuverlässig verhindert. Dieser Artikel erklärt die Funktionsweise, die Performance-Kosten und wann sich eine Deaktivierung überhaupt lohnt.

N+1-Queries entstehen fast immer unbemerkt in ORM-generiertem Code und summieren sich unter Last zu Hunderten zusätzlicher Datenbankzugriffe pro Seitenaufruf. Diese Methodik zeigt, wie man N+1-Queries im Query-Log systematisch aufspürt, mit Eager Loading und Batch-Loading behebt und den Performance-Gewinn mit EXPLAIN ANALYZE konkret misst.

Gap Locks gehören zu den am wenigsten verstandenen Mechanismen von InnoDB und lösen in der Praxis regelmäßig überraschende Lock Waits aus, ohne dass eine konkrete Zeile betroffen zu sein scheint. Dieser Artikel erklärt, was Gap Locks konkret sind, warum InnoDB sie unter REPEATABLE READ zur Vermeidung von Phantom Reads braucht, und wie Next-Key Locks als Kombination aus Record Lock und Gap Lock funktionieren.

cron_schedule protokolliert jeden geplanten und ausgeführten Cron-Job in Magento und kann bei falscher Konfiguration innerhalb weniger Wochen Millionen Zeilen ansammeln. Wer die Statusübergänge der Tabelle versteht, history_cleanup_every richtig einstellt und bei Bedarf manuell nachhilft, verhindert langsame Cron-Läufe und Locking-Probleme in der Produktion.

Ein zu breiter INT, ein VARCHAR-Feld, das eigentlich TEXT sein sollte, oder FLOAT statt DECIMAL für Geldbeträge summieren sich in großen Tabellen zu erheblichem, oft übersehenem Speicherplatzbedarf und Performance-Verlust. Die Wahl des richtigen Datentyps ist eine der günstigsten Optimierungen im gesamten Datenbankdesign. Dieser Artikel erklärt die wichtigsten Datentyp-Entscheidungen mit konkreten Sizing-Regeln.

Ein Deadlock in InnoDB ist kein Bug, sondern eine unvermeidliche Konsequenz paralleler Transaktionen, die sich gegenseitig blockieren. Dieser Artikel zeigt, wie man den Deadlock-Report von SHOW ENGINE INNODB STATUS liest, welche Muster in der Praxis immer wieder auftreten, und wie Retry-Logik zusammen mit konsistenter Lock-Reihenfolge Deadlocks systematisch reduziert.