Seite 4 - MySQL

Ein falsch dimensioniertes Connection-Pooling führt entweder zu Too-many-connections-Fehlern unter Last oder zu verschwendeten Ressourcen durch tausende ungenutzte Leerlaufverbindungen. Dieser Artikel zeigt, wie max_connections richtig dimensioniert wird, wie wait_timeout und interactive_timeout zusammenspielen, wie PHP-FPM-Pool-Größe und MySQL-Verbindungslimit aufeinander abgestimmt werden und wann ein externer Connection Pooler wie ProxySQL sinnvoll ist.

Der InnoDB Buffer Pool entscheidet darüber, ob eine Abfrage aus dem Arbeitsspeicher in Mikrosekunden beantwortet wird oder eine langsame Festplattenoperation auslöst. Wer innodb_buffer_pool_size falsch dimensioniert oder die LRU-Liste nicht versteht, verschenkt Performance, die keine Indexoptimierung wieder aufholen kann. Dieser Artikel erklärt Aufbau, Sizing-Methodik und Monitoring des Buffer Pools mit echten SQL-Beispielen.

Das EAV-Schema erlaubt Magento beliebig viele Produktattribute ohne ALTER TABLE, erkauft das aber mit Join-Aufwand bei jeder Produktabfrage. Wer die Tabellenstruktur aus entity-, attribute- und typspezifischen value-Tabellen versteht, kann echte Engpässe von vermeintlichen EAV-Problemen unterscheiden und gezielt mit Flat-Tables oder eigenen Index-Tabellen gegensteuern.

Das Binlog-Format entscheidet darüber, ob MySQL-Replikation bei nicht-deterministischen Statements zuverlässig bleibt oder still auseinanderdriftet. STATEMENT, ROW und MIXED unterscheiden sich fundamental in Größe, Sicherheit und Nachvollziehbarkeit, und die Wahl des richtigen Formats ist eine der folgenreichsten Konfigurationsentscheidungen in jeder MySQL-Installation.

Das Percona Toolkit ist eine Sammlung von Kommandozeilenwerkzeugen, die genau die Luecken schliessen, die MySQL selbst offenlaesst: Schema-Aenderungen ohne Sperren, systematische Slow-Query-Analyse und verlaessliche Replikationskonsistenz. Wer diese Tools gezielt gegen eine Magento-Datenbank einsetzt, gewinnt Kontrolle ueber Bereiche, die sonst nur mit riskanten manuellen Eingriffen zu handhaben waeren.

Optimizer-Hints wie USE INDEX, FORCE INDEX und STRAIGHT_JOIN greifen direkt in die Entscheidungen des Query-Optimizers ein und können bei falscher Statistik echte Probleme lösen, aber auch neue schaffen, wenn sie unreflektiert eingesetzt werden. Dieser Artikel zeigt die Syntax, die Wirkung und die klare Grenze zwischen legitimer Optimierung und riskantem Code Smell.

Ohne konsequente Tabellen-Archivierung sammeln sich in quote und sales_order Millionen verwaister Warenkorb-Zeilen und Jahre alter Bestellhistorie an, die jede Abfrage verlangsamen und Backups aufblaehen. Eine durchdachte Archivierungsstrategie trennt aktive Transaktionsdaten von historischen Datenbestaenden, ohne referenzielle Integritaet oder Compliance-Anforderungen zu gefaehrden.

Ein Index auf eine Spalte mit nur zwei möglichen Werten bringt fast nie eine spürbare Beschleunigung, egal wie groß die Tabelle ist. Cardinality beschreibt die Anzahl unterschiedlicher Werte in einer Spalte, Selektivität ihr Verhältnis zur Zeilenanzahl, und beide Kennzahlen entscheiden gemeinsam mit dem Optimizer, ob ein Index überhaupt genutzt wird.

Nicht jedes Suchfeld braucht sofort Elasticsearch. MySQL bringt mit FULLTEXT-Indizes, Natural Language Mode und Boolean Mode eine vollwertige Volltextsuche direkt in der Datenbank mit, die für viele Anwendungen ausreicht, ohne zusätzliche Infrastruktur, zusätzliche Latenz und zusätzliche Konsistenzprobleme zwischen zwei Systemen.

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.