Seite 16 - SQL

JSON MySQL: Wann JSON-Spalten sinnvoll sind, wie JSON_EXTRACT, JSON_SET und JSON_TABLE funktionieren, wie man JSON-Pfade indiziert und was MariaDB anders macht.

Ein Running Total, also eine kumulative Summe, die mit jeder Zeile wachst, gehort zu den haufigsten Anforderungen in Kontoauszugen, Umsatzberichten und Bestandsverwaltungen. Mit SUM() OVER lasst sich diese Berechnung direkt in SQL losen, ohne den langsamen Umweg uber eine korrelierte Subquery. Dieser Artikel zeigt die Syntax, den Reset pro Gruppe und den konkreten Performance-Unterschied.

Eine Transaktion, die vergessen wurde zu committen, blockiert kein einzelnes Query, sondern verhindert im Hintergrund Vacuum, blockiert Locks und bläht Undo-Strukturen auf, ohne dass eine einzelne langsame Abfrage im Slow-Query-Log auftaucht. Wer Idle-in-Transaction-Sessions systematisch über Session-Views erkennt, findet die Ursache im Anwendungscode, statt nur an Symptomen zu kurieren.

Row Level Security verlagert Zugriffsregeln aus der Anwendungsschicht in die Datenbank selbst und filtert jede Zeile automatisch nach dem aktuellen Sicherheitskontext. Wer Multi-Tenancy oder mandantenfeindliche Anwendungslogik ohne Row Level Security absichert, verlaesst sich auf disziplinierte WHERE-Klauseln in jedem einzelnen Query, und genau das bricht frueher oder spaeter.

Ein Domain-Typ bündelt einen Basisdatentyp mit einem oder mehreren Constraints zu einem eigenen, benannten Typ, den beliebig viele Tabellen und Spalten wiederverwenden können. Dieser Beitrag zeigt CREATE DOMAIN und ALTER DOMAIN im Detail, praktische Beispiele für E-Mail-Adressen und positive Beträge, Migrationen bestehender Spalten und die Grenzen dieses Ansatzes gegenüber Constraints pro Spalte.

Tausend einzelne INSERT-Statements sind fast immer langsamer als dieselben tausend Zeilen in einem einzigen Batch, weil jeder einzelne Round-Trip zur Datenbank Netzwerk-Latenz, Parsing und Transaktions-Overhead kostet. Batch-Processing buendelt diese Kosten, egal ob ueber Multi-Row-INSERTs, Bulk-Load-Tools oder groessere Transaktionen, und kann die Ladezeit um eine Groessenordnung senken.

Ein Covering Index enthält alle Spalten, die eine Query braucht — kein Tabellen-Lookup, maximale Performance. So baust du sie für Magento richtig.

Der Index ist angelegt, die Spalte ist ausgewählt, trotzdem zeigt EXPLAIN einen vollständigen Table Scan. Dieses Muster hat fast immer eine von wenigen konkreten Ursachen: Funktionen auf der indizierten Spalte, implizite Typkonvertierung, führende Wildcards oder veraltete Statistiken. Diese Anleitung zeigt eine feste Reihenfolge, mit der sich die Ursache in wenigen Minuten eingrenzen lässt.

Eine begrenzte Anzahl Zeilen aus einer Abfrage zurueckzugeben klingt nach einer trivialen Aufgabe, doch MySQL, PostgreSQL, SQL Server und Oracle schreiben diese Begrenzung mit vier vollstaendig unterschiedlichen Syntaxformen. Wer Pagination-Code zwischen diesen Systemen portabel halten will, braucht den Ueberblick ueber LIMIT, TOP, ROWNUM und den gemeinsamen ANSI-Standard-Nenner OFFSET FETCH.

Eine einzelne Common Table Expression macht eine Abfrage schon deutlich lesbarer als eine tief verschachtelte Subquery, aber der eigentliche Mehrwert zeigt sich erst, wenn mehrere CTEs nacheinander aufeinander aufbauen und eine komplexe Auswertung in klar benannte, nachvollziehbare Zwischenschritte zerlegen. Diese Lesbarkeit hat allerdings ihren Preis, denn nicht jede Datenbank behandelt eine Kette aus CTEs technisch gleich: Manche materialisieren jede CTE als eigenständiges Zwischenergebnis, andere binden sie transparent in die umgebende Abfrage ein. Dieser Artikel zeigt, wie sich mehrstufige CTE-Ketten sinnvoll strukturieren lassen, wie sich das Materialisierungsverhalten zwischen PostgreSQL vor und nach Version 12 sowie anderen Datenbanken unterscheidet, und ab welchem Punkt eine CTE-Kette in der Praxis zum echten Performance-Problem wird.