MySQL: Anleitungen und Praxiswissen | Seite 9 | mironsoft Blog
MySQL
-
22.03.2025
Ein Composite-Index aus den richtigen Spalten in der falschen Reihenfolge ist für den Optimizer oft wertlos. Die Leftmost-Prefix-Regel bestimmt, welcher Teil eines Composite-Index überhaupt genutzt werden kann, und wer Equality-Spalten vor Range-Spalten anordnet, bekommt aus demselben Index spürbar schnellere Abfragen ohne zusätzlichen Speicherplatz.
-
21.03.2025
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.
-
12.03.2025
InnoDB kann Tabellen seitenweise komprimieren, ohne dass die Anwendung davon etwas mitbekommt. Der Mechanismus dahinter, die Wahl der richtigen KEY_BLOCK_SIZE und der Trade-off zwischen Speicherplatzersparnis und zusätzlichem CPU-Overhead entscheiden aber darüber, ob sich ROW_FORMAT=COMPRESSED für eine konkrete Tabelle wirklich lohnt. Für Magento-Installationen mit umfangreichen Log- und Archivtabellen kann die Kompression spürbar Plattenplatz und Cache-Druck reduzieren, für heiß beschriebene Kerntabellen kann sie dagegen zur Bremse werden.
-
09.03.2025
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.
-
08.03.2025
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.
-
04.03.2025
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.
-
03.03.2025
Nicht jede ALTER-TABLE-Anweisung ist in MySQL gleich teuer. Manche Änderungen sind reine Metadaten-Operationen, die in Millisekunden abgeschlossen sind, andere kopieren im Hintergrund die komplette Tabelle und blockieren Schreibzugriffe für Sekunden oder Minuten. Wer bei mehreren hundert Gigabyte großen Magento-Tabellen den Unterschied zwischen ALGORITHM=INSTANT, INPLACE und COPY nicht kennt, riskiert ungeplante Downtime mitten im Tagesgeschäft.
-
20.02.2025
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.
-
12.02.2025
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.
-
12.02.2025
InnoDB speichert Daten als B-Tree und ist damit die Standardwahl für nahezu jede MySQL-Installation, auch bei Magento-Shops. Bei sehr hoher Schreiblast, etwa in Logging-Tabellen, Änderungsprotokollen oder Zeitreihendaten, stößt dieser Ansatz jedoch an Grenzen: Random Writes erzeugen Seiten-Splits und spürbare Write Amplification. MyRocks ersetzt den B-Tree durch einen Log-Structured-Merge-Tree, wie er aus RocksDB stammt, und verspricht dafür deutlich weniger Schreib-Overhead und kleinere Tabellen auf der Platte. Ob sich der Umstieg lohnt, hängt stark vom tatsächlichen Zugriffsmuster ab.