MySQL: Anleitungen und Praxiswissen | Seite 4 | mironsoft Blog
MySQL
-
10.12.2025
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.
-
06.12.2025
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.
-
04.12.2025
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.
-
03.12.2025
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.
-
29.11.2025
Seit MySQL 8 lassen sich Baumstrukturen und andere hierarchische Daten über WITH RECURSIVE direkt in SQL auflösen, ohne dafür rekursive Anwendungslogik oder eine feste Anzahl von Self-Joins zu benötigen. Die grundlegende Syntax folgt dem SQL-Standard, doch MySQL bringt einige eigene Implementierungsdetails mit, von der internen Umsetzung als UNION-Schleife bis zum konfigurierbaren Endlosschleifen-Schutz über cte_max_recursion_depth. Dieser Artikel zeigt, wie rekursive CTEs in MySQL intern arbeiten, wo typische Fallstricke liegen und wie sich ein Magento-Kategoriebaum damit praktisch und performant auflösen lässt.
-
26.11.2025
Die Indexer-Tabellen sind das Rückgrat der Magento-Performance auf Kategorie- und Suchseiten, weil sie EAV-Joins durch vorberechnete, flache Strukturen ersetzen. Wer die Struktur von catalog_category_product_index und catalog_product_index_price kennt und die Modi Update on Save und Update on Schedule richtig einordnet, kann Reindex-Läufe gezielt tunen statt sie als Blackbox hinzunehmen.
-
24.11.2025
Der MySQL Query Cache versprach schnellere Leseanfragen durch einfaches Wiederverwenden von Ergebnissen, scheiterte aber an einem einzigen globalen Lock, der bei jedem Schreibzugriff die gesamte Instanz ausbremste. Dieser Artikel erklärt die Architektur, die konkreten Bottlenecks, die Abschaffung in MySQL 8.0 und wie Redis- und ORM-basiertes Caching den Query Cache heute sauberer ersetzt.
-
22.11.2025
InnoDB hat MyISAM seit MySQL 5.5 als Standard-Storage-Engine abgelöst, doch in gewachsenen Systemen taucht MyISAM immer noch auf, oft unbemerkt. Wer Transaktionsverhalten, Locking-Granularität und Crash Safety der beiden Engines nicht kennt, riskiert bei Migrationen und Legacy-Wartung Datenverlust. Dieser Artikel erklärt die Unterschiede im Detail und zeigt, wie eine saubere Migration zu InnoDB aussieht.
-
22.11.2025
Wer eine ganze Transaktion zurückrollt, nur weil ein einzelner Schritt innerhalb eines größeren Batch-Vorgangs fehlschlägt, verschenkt bereits erledigte Arbeit. Savepoints erlauben es, gezielt zu einem markierten Punkt innerhalb einer Transaktion zurückzukehren, ohne die vorherigen Änderungen zu verlieren. Dieser Artikel zeigt die vollständige SAVEPOINT-Syntax in MySQL, erklärt das Verhalten in InnoDB im Detail und liefert Praxisbeispiele für Batch-Imports und die Implementierung in PHP mit PDO.
-
21.10.2025
MySQL Group Replication baut einen selbstverwaltenden Cluster direkt in der Datenbank auf, inklusive Konfliktprüfung, Gruppenmitgliedschaft und automatischem Failover, ohne dass ein externer Orchestrator die Rolle des Primary bestimmen muss. Das reduziert die Anzahl beweglicher Teile in der Hochverfügbarkeitsarchitektur erheblich.