Antwort.

In SQL ist häufig eine dynamische Filterung erforderlich — z. B. in Berichten oder Suchen, wenn Filter vom Benutzer festgelegt werden. Die grundlegenden Ansätze sind:

Dynamisches SQL — Die Abfrage wird zur Laufzeit mit Bedingungen nur für nicht leere Parameter erstellt. Das ist flexibel, erfordert jedoch besondere Aufmerksamkeit auf den Schutz vor SQL-Injection (Verwendung von Parametern/Escaping).
Bedingte Filterung über OR — Verwendung von Konstruktionen (@param IS NULL OR Feld = @param), damit überflüssige Bedingungen das Ergebnis nicht beeinflussen, wenn der Parameter nicht festgelegt ist. Dieser Ansatz ist sicher, kann aber manchmal zu suboptimalem Indexeinsatz führen.

Beispiel eines Templates zur Suche nach Bestellungen:

SELECT * FROM Orders
WHERE
    (@CustomerID IS NULL OR CustomerID = @CustomerID)
    AND (@Status IS NULL OR Status = @Status)
    AND (@DateFrom IS NULL OR OrderDate >= @DateFrom)
    AND (@DateTo IS NULL OR OrderDate <= @DateTo);

Fangfrage.

Frage: Warum verschlechtert sich manchmal die Leistung bei Verwendung des Ansatzes (@param IS NULL OR Column = @param) — selbst bei vorhandenen Index auf Column?

Antwort: Diese Vorlage hindert den Optimierer daran, den Index effizient zu nutzen, da die Bedingung eine Variable enthält, und die Abfrage sich in einen vollständigen Tabellen-Scan anstelle einer Indexsuche verwandelt. Bei großen Datenmengen ist das kritisch.

Beispiel:

WHERE (@name IS NULL OR name = @name)

Diese Bedingung ist nicht dasselbe wie einfach name = @name, was es der DBMS nicht erleichtert, den Index zu verwenden.

Geschichte

Im Suchdienst für die Kundendatenbank wurden "flexible Filter" über die Vorlage (@par IS NULL OR Field = @par) eingeführt, und mit dem Anstieg des Bestellvolumens sank die Suchgeschwindigkeit von Sekunden auf Minuten — die Indizes funktionierten nicht mehr, da der Optimierer den spezifischen Wert nicht bestimmen konnte.

Geschichte

Im E-Commerce-Projekt wurde die Filterung über dynamisches SQL ohne Parameter durchgeführt, indem Werte direkt eingefügt wurden. Injektionen ermöglichten es den Benutzern, Listen aller Kunden zu erhalten, da der Filter anfällig war — Passwörter mussten dringend geändert werden.

Geschichte

BI-Berichte wurden über eine parametrisierte Vorlage erstellt, ohne zu berücksichtigen, dass OR-Bedingungen indexierte Scans ausschließen. Bei Millionen von Datensätzen „blieben“ die Berichte stehen, bis die Filterung auf die optimale Variante mit verbindlichen Bedingungen und separater Logik für verschiedene Kombinationen von Parametern umgeschrieben wurde.

Wie implementiert man bedingte Logik zur Datenfilterung in SQL richtig und effizient, wenn die Suchparameter dynamisch festgelegt werden (z. B. ein Webfilter mit beliebigem Set von Bedingungen)?

Antwort.

Fangfrage.