Seite 8 - SQL

Was steckt wirklich hinter innodb_buffer_pool_size, Redo Log Kapazität und Flush-Verhalten? Ein praxisnaher Guide für Magento-Entwickler ohne Halbwissen.

InnoDB Sperren sind das unsichtbare Fundament jeder Transaktion. Wer nicht unterscheidet, was Record Locks, Gap Locks und Next-Key Locks trennt, produziert Deadlocks und Timeouts — besonders unter Last.

Ein Savepoint markiert einen Zwischenpunkt innerhalb einer laufenden Transaktion, zu dem später zurückgerollt werden kann, ohne die gesamte Transaktion aufzugeben. Gerade in der Batch-Verarbeitung erlaubt dieses Werkzeug, einzelne fehlgeschlagene Elemente zu verwerfen, während der bereits erfolgreiche Teil der Arbeit erhalten bleibt.

Volume-Verschluesselung schuetzt Daten nur gegen gestohlene Festplatten, nicht aber gegen einen kompromittierten Datenbank-Account, der ganz normal per SQL liest. Datenverschluesselung auf Spaltenebene schuetzt genau diese Luecke, verlangt aber durchdachte Entscheidungen bei Schluesselverwaltung, Suchbarkeit und Indizierung, die pauschale Volume-Verschluesselung nie stellen muss.

Eine rekursive CTE loest genau die Aufgabe, an der eine normale Abfrage scheitert: Baumstrukturen unbekannter Tiefe in einem einzigen SQL-Statement durchlaufen. Mit WITH RECURSIVE werden Kategoriebaeume, Organigramme und Stuecklisten ohne Anwendungscode und ohne feste Verschachtelungstiefe ausgewertet, solange Ankeranfrage, rekursiver Teil und Terminierungsbedingung sauber definiert sind.

Eine Funktion wie YEAR() oder LOWER() auf einer indizierten Spalte kostet den Index — MySQL muss jede Zeile auswerten. Was SARGable Query bedeutet und wie man Queries korrekt umschreibt, zeigt dieser Artikel.

Eine correlated Subquery unterscheidet sich von einer normalen Subquery dadurch, dass sie eine Spalte der aeusseren Abfrage referenziert und deshalb logisch fuer jede einzelne aeussere Zeile neu ausgewertet werden muss. Dieser eine Unterschied erklaert sowohl ihre Ausdrucksstaerke bei Zeile-fuer-Zeile-Logik als auch ihr groesstes Performance-Risiko, wenn der Optimizer die wiederholte Ausfuehrung nicht in einen effizienten Join umwandeln kann.

Wer Datenbank-Migrationen ungetestet gegen Produktion fahren laesst, riskiert Datenverlust, lange Downtime und stille Inkonsistenzen. Mit einer klaren Teststrategie aus Expand-Contract-Pattern, Rollback-Proben und automatisierten Pipelines werden Schema-Aenderungen planbar statt riskant.

Wer langsame Queries erst findet, wenn Nutzer sich beschweren, arbeitet reaktiv statt praeventiv. Mit Slow Query Log, pg_stat_statements und einem klaren Sampling-Prozess lassen sich langsame Queries systematisch aufspueren, bevor sie zum Produktionsproblem werden, unabhaengig davon, welches Datenbanksystem im Einsatz ist.

Wer allen Anwendungen und Entwicklern denselben Datenbank-Account mit vollen Rechten gibt, macht jede zukuenftige Sicherheitsluecke automatisch zu einem Totalschaden. Granulare Datenbank-Benutzerrechte, aufgebaut aus GRANT-Anweisungen, Rollenhierarchien und dem Least-Privilege-Prinzip, begrenzen den Schaden eines einzelnen kompromittierten Accounts auf genau das, was dieser Account wirklich braucht.