Ist ein SQL-Subselect mit DISTINCT schneller?

Nein, DISTINCT macht einen Subselect nicht automatisch schneller; es kann wirkungslos sein oder zusätzliche Arbeit verursachen.

DISTINCT entfernt doppelte Ergebniszeilen. Ob sich das lohnt, hängt davon ab, wie die Unterabfrage verwendet wird und welchen Ausführungsplan die Datenbank wählt. Es ist deshalb kein allgemeiner Performance-Schalter.

Entscheidend ist die Verwendung

• Bei IN oder EXISTS: Duplikate ändern nicht, ob ein passender Datensatz existiert. MySQL ignoriert DISTINCT ausdrücklich, wenn die Unterabfrage die Voraussetzungen für eine Semijoin-Optimierung erfüllt. Dann bringt das zusätzliche Schlüsselwort keinen Vorteil.
• Bei einer Unterabfrage als JOIN-Eingabe: DISTINCT kann die weiterzuverarbeitende Zeilenmenge reduzieren. Dafür müssen zunächst Duplikate entfernt werden. Ob die Gesamtabfrage dadurch gewinnt, muss der Ausführungsplan zeigen. Wichtig: Das Entfernen von Duplikaten kann hier auch das Ergebnis verändern.

Konkretes Beispiel und Prüfung

Bei dieser Abfrage ist DISTINCT für das Ergebnis nicht erforderlich:

SELECT *
FROM kunden
WHERE id IN (
    SELECT DISTINCT kunden_id
    FROM bestellungen
);

Ob eine Kunden-ID in der Unterabfrage einmal oder mehrfach vorkommt, ändert die Zugehörigkeitsprüfung nicht. Unter den genannten MySQL-Optimierungsbedingungen wird DISTINCT daher ignoriert.

Praktisch sinnvoll: Vergleiche beide Varianten anhand des tatsächlichen Ausführungsplans. In PostgreSQL liefert EXPLAIN ANALYZE tatsächliche Laufzeiten und Zeilenzahlen, führt die Abfrage dabei aber wirklich aus. Entscheidend ist die gesamte Abfrage, nicht nur der Subselect.

Quellen:

• Optimizing IN and EXISTS Subquery Predicates with Semijoin and Antijoin Transformations, MySQL
• SELECT, PostgreSQL
• Using EXPLAIN, PostgreSQL