Seite 3 - SQL

Eine Datenbank mit niedriger CPU-Auslastung kann trotzdem drastisch langsam antworten, weil Sessions in Wirklichkeit auf Locks, Festplatten-IO oder Netzwerk warten, nicht auf freie Rechenzeit. Wait Events machen genau diese unsichtbare Wartezeit messbar und kategorisierbar. Wer systematisch zwischen Lock Waits und IO Waits unterscheidet, findet die tatsächliche Root Cause, statt an CPU- oder Speichermetriken vorbeizuoptimieren.

MySQL Temp Tables sind mächtiger als die meisten Entwickler vermuten. Wann MySQL intern Disk-Tabellen erzeugt, wie tmp_table_size und max_heap_table_size zusammenspielen, was CTE-Materialisierung in MySQL 8 bedeutet — und wie explizite Temp Tables komplexe Reports dramatisch beschleunigen.

Eine Schema-Migration ohne klare Versionierung und Rollback-Plan wird auf einer großen produktiven Tabelle schnell zum Risiko. Dieser Beitrag zeigt Namenskonventionen für Migrationsdateien, den Unterschied zwischen forward-only und reversible Migrations, das Expand-Contract-Pattern und sichere Vorgehensweisen für NOT NULL-Spalten an Tabellen mit Millionen Zeilen, mit konkretem SQL für jeden Schritt.

Konfiguration, Store-Hierarchie, EAV-System, CMS-Seiten, URL-Rewrites und Berechtigungen – alle wesentlichen Magento Core-Tabellen erklärt, mit SQL-Abfragen zum direkten Einsatz.

Partitionierung und Sharding tauchen in Architekturdiskussionen häufig als Synonyme auf, obwohl sie technisch grundverschiedene Probleme lösen. Partitionierung teilt eine große Tabelle innerhalb einer einzigen Datenbankinstanz in kleinere, physisch getrennte Segmente auf, während Sharding Daten über mehrere unabhängige Datenbankinstanzen hinweg verteilt. Wer diesen Unterschied nicht sauber trennt, unterschätzt entweder den Betriebsaufwand von Sharding oder verpasst die Chance, mit dem deutlich einfacheren Werkzeug Partitionierung ein Problem zu lösen, das gar kein verteiltes System braucht.

Prepared Statements stoppen die klassische SQL-Injection an der Eingabemaske, aber laengst nicht jeder Vektor laeuft ueber ein einzelnes Formularfeld. Second-Order-Injection, Blind-Injection ohne sichtbare Fehlermeldung, Out-of-Band-Exfiltration ueber DNS und Injection in Identifier-Kontexten wie ORDER BY umgehen genau die Schutzmassnahmen, auf die sich Teams meist verlassen.

Manche Datenbankprobleme sind keine Frage von fehlenden Indizes oder schlecht formulierten Abfragen, sondern liegen tiefer im Schema-Design selbst begründet. Diese strukturellen Antipatterns wiederholen sich über Projekte und Branchen hinweg auffallend gleichförmig: eine generische Attributtabelle, die jede Validierung unmöglich macht, eine Spalte pro Wiederholung statt einer eigenen Zeile, ein Fremdschlüssel ohne begleitenden Index. Jedes dieser Muster beginnt harmlos und pragmatisch, wird aber mit wachsendem Datenvolumen zu einem handfesten Performance- und Wartungsproblem. Diese Sammlung ordnet die häufigsten Fälle nach Symptom, Ursache und Refactoring-Weg.

Sobald eine Transaktion mehrere unabhängige Datenbanken oder Services betrifft, reicht ein einfaches COMMIT nicht mehr aus, um Atomarität zu garantieren. Two-Phase Commit löst dieses Problem über ein Koordinator-basiertes Prepare-und-Commit-Protokoll, hat aber strukturelle Schwächen, die in großen, verteilten Systemen heute meist den Saga Pattern-Ansatz mit kompensierenden Aktionen bevorzugen lassen.

Dynamic Data Masking löst ein Problem, das klassische Zugriffskontrollen nur unvollständig abdecken: Ein Supportmitarbeiter braucht Zugriff auf eine Kundentabelle, um eine Bestellung zu finden, aber nicht auf die vollständige Kreditkartennummer oder die private E-Mail-Adresse dahinter. Statt zwei getrennte Kopien der Tabelle zu pflegen oder Anwendungslogik mit Sichtbarkeitsregeln zu überladen, maskiert die Datenbank selbst bestimmte Spaltenwerte zur Laufzeit, abhängig davon, welche Rolle die aktuelle Verbindung hat. Dieser Artikel erklärt die Funktionsweise, zeigt praktische Regeln für verschiedene Datentypen und macht deutlich, wo die Grenzen des Verfahrens liegen.

Eine Migration, die spontan eine Spalte umbenennt oder eine Tabelle sperrt, kann eine laufende Symfony-Anwendung mitten in der Rush Hour lahmlegen. Zero Downtime Datenbankmigrationen mit Doctrine folgen stattdessen dem Expand-Contract-Muster: Schema und Anwendung wachsen in kleinen, immer rückwärtskompatiblen Schritten. Dieser Artikel zeigt jeden Schritt konkret, von der ersten neuen Spalte bis zum sicheren Entfernen der alten.