SQL Interview Prep · Lektion

Unendliche Rekursion vermeiden

Zykluserkennung, Tiefenbegrenzungen und die Rekursionssicherung, nach der jeder Interviewer fragt

Unendliche Rekursion vermeiden ist eine kostenlose SQL Interview Prep-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des SQL Interview Prep-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der SQL Interview Prep-Kurs umfasst insgesamt 4 Lektionen.

Die Frage hinter der Frage

Nachdem Sie eine rekursive CTE geschrieben haben, fragt ein aufmerksamer Interviewer: „Was passiert, wenn die Daten einen Zyklus enthalten?“ Damit wird geprüft, ob Sie verstehen, dass Rekursion unendlich laufen kann — und ob Sie wissen, wie Sie dies verhindern.

Ein Zyklus liegt vor, wenn eine Hierarchie auf sich selbst zurückverweist: A berichtet an B, B berichtet an A. Der naive rekursive Teil würde unendlich zwischen den beiden hin- und herspringen.

Wie ein Zyklus entsteht

Bäume sollten azyklisch sein, aber reale Daten sind oft fehlerhaft. Eine fehlerhafte Aktualisierung kann dazu führen, dass ein Mitarbeiter sein eigener (indirekter) Vorgesetzter wird. Ein Graph — etwa „Benutzer, die anderen Benutzern folgen“ — ist von Natur aus zyklisch.

Wenn der rekursive Teil einen bereits besuchten Knoten erneut antrifft, erzeugt er diesen Knoten erneut, wodurch dessen Kindknoten wieder verarbeitet werden und die Schleife nie endet. Die Rekursion endet nur, wenn ein Schritt keine Zeilen zurückgibt; ein Zyklus garantiert, dass stets Zeilen zurückgegeben werden.

Schutzmechanismus 1: Eine Tiefenbegrenzung

Die einfachste Sicherheitsmaßnahme ist ein Tiefenzähler mit einer Obergrenze im rekursiven Teil. Auch wenn ein Zyklus vorhanden ist, endet die Rekursion an dieser Grenze.

Das ist eine grobe Maßnahme — sie begrenzt auch berechtigt tiefe Bäume — aber sie ist schnell umgesetzt und für Interviews geeignet.

WITH RECURSIVE org AS (
    SELECT id, name, manager_id, 1 AS depth
    FROM employees WHERE manager_id IS NULL
    UNION ALL
    SELECT e.id, e.name, e.manager_id, o.depth + 1
    FROM employees e JOIN org o ON e.manager_id = o.id
    WHERE o.depth < 50
)
SELECT * FROM org;

Schutzmechanismus 2: Ein Pfad besuchter Knoten

Eine präzise Absicherung verfolgt den Pfad der besuchten Knoten und verhindert, dass ein Knoten erneut betreten wird, der bereits auf dem Pfad liegt. Sammeln Sie die IDs in einer Zeichenkette (oder einem Array) und prüfen Sie vor der Rekursion, ob die ID bereits enthalten ist.

So werden Zyklen präzise gestoppt, während legitime Bäume weiterhin eine beliebige Tiefe haben können.

WITH RECURSIVE org AS (
    SELECT id, name, manager_id,
           CAST(',' || id || ',' AS VARCHAR(2000)) AS path
    FROM employees WHERE manager_id IS NULL
    UNION ALL
    SELECT e.id, e.name, e.manager_id,
           o.path || e.id || ','
    FROM employees e JOIN org o ON e.manager_id = o.id
    WHERE o.path NOT LIKE '%,' || e.id || ',%'
)
SELECT id, name, path FROM org;

Warum die Pfadprüfung funktioniert

Die Bedingung path NOT LIKE '%,' || e.id || ',%' bedeutet: „Folgen Sie dieser Kante nur, wenn die ID des Kindes noch nicht im Pfad enthalten ist.“ Die Kommas dienen als Trennzeichen, sodass die ID 1 nicht fälschlicherweise innerhalb der ID 15 gefunden wird.

Wenn ein Zyklus einen Knoten erneut besuchen würde, filtert das WHERE diese Zeile heraus, der rekursive Teil liefert schließlich nichts zurück und die Rekursion endet ordnungsgemäß.

Schutzmechanismus 3: Die native CYCLE-Klausel

Modernes Postgres (14+) und der SQL-Standard bieten eine integrierte CYCLE-Klausel, die die Pfadprüfung automatisiert und Zyklen für Sie kennzeichnet. Wenn die Engine dies unterstützt, ist das die sauberste Lösung.

WITH RECURSIVE org AS (
    SELECT id, name, manager_id FROM employees WHERE manager_id IS NULL
    UNION ALL
    SELECT e.id, e.name, e.manager_id
    FROM employees e JOIN org o ON e.manager_id = o.id
)
CYCLE id SET is_cycle USING cycle_path
SELECT id, name, is_cycle FROM org;

MAXRECURSION in SQL Server

SQL Server begrenzt standardmäßig auf 100 Rekursionsebenen. Wenn ein Zyklus (oder ein tiefer Baum) diese Grenze überschreitet, bricht die Abfrage mit einem Fehler ab, statt endlos zu laufen — ein impliziter Sicherheitsmechanismus.

Sie können die Grenze mit OPTION (MAXRECURSION n) erhöhen oder aufheben, wobei 0 unbegrenzt bedeutet. Wenn Sie die Grenze ohne eine Pfadprüfung entfernen, besteht bei zyklischen Daten erneut das Risiko einer Endlosschleife.

-- Cap recursion at 200 levels in SQL Server
SELECT * FROM org
OPTION (MAXRECURSION 200);

Zyklen erkennen oder verhindern

Interviewer unterscheiden möglicherweise zwischen zwei Zielen:

Verhindern — die zyklische Kante still überspringen, damit die Abfrage abgeschlossen wird (das Pfadprüfungs-WHERE).
Erkennen und melden — sichtbar machen, welche Zeilen Teil eines Zyklus sind, damit ein Datenteam die fehlerhaften Daten korrigieren kann (das is_cycle-Flag der CYCLE-Klausel).

Beides zu kennen und zu wissen, wann welches Vorgehen angemessen ist, ist eine Unterscheidung auf Senior-Ebene.

Überlegungen zur Performance

Rekursion kann auch ohne Zyklen kostspielig sein. Tipps, die Interviewer gern hören:

Die Verknüpfungsspalte (z. B. manager_id) indizieren, damit der Join jeder Iteration schnell ist.
Bereits im Anker filtern, um nur den benötigten Teilbaum und nicht die gesamte Tabelle als Ausgangspunkt zu verwenden.
SELECT * vermeiden — nur die für die Rekursion erforderlichen Spalten sowie depth/path mitführen.

Eine sichere Vorlage

Kombinieren Sie die Schutzmechanismen in einer Vorlage, die Sie auch unter Druck reproduzieren können: eine Tiefenspalte als Rückfallebene und eine Pfadprüfung als präzise Absicherung. Auch wenn beides bei sauberen Daten übertrieben sein kann, zeigt die Verwendung beider Maßnahmen Gründlichkeit.

WITH RECURSIVE walk AS (
    SELECT id, parent_id, 1 AS depth,
           CAST(',' || id || ',' AS VARCHAR(4000)) AS path
    FROM nodes WHERE parent_id IS NULL
    UNION ALL
    SELECT n.id, n.parent_id, w.depth + 1,
           w.path || n.id || ','
    FROM nodes n JOIN walk w ON n.parent_id = w.id
    WHERE w.depth < 100
      AND w.path NOT LIKE '%,' || n.id || ',%'
)
SELECT id, depth FROM walk;

Häufige Fehler im Interview

Letzte Fallen, die Sie vermeiden sollten:

MAXRECURSION in SQL Server ohne eine andere Absicherung entfernen — dadurch besteht erneut das Risiko einer Endlosschleife.
Eine als zu kurz deklarierte Spalte für die Pfadzeichenkette verwenden, wodurch sie abgeschnitten wird und die Absicherung unbemerkt nicht mehr funktioniert.
IDs ohne Kommatrennzeichen vergleichen, sodass die ID 1 fälschlicherweise innerhalb der ID 21 gefunden wird.
Annehmen, dass die Daten azyklisch sind, nur weil sie es „sein sollten“ — fragen Sie immer nach.

Kurze Überprüfung

Wählen Sie den Schutzmechanismus, der Zyklen präzise stoppt, ohne die legitime Tiefe zu begrenzen.

Zusammenfassung

Jede Antwort zu einer rekursiven CTE sollte die Sicherheit berücksichtigen:

Zyklen sorgen dafür, dass der rekursive Teil nie eine leere Ergebnismenge zurückgibt und die Rekursion daher nie endet.
Tiefenbegrenzung = schnelle Rückfallebene; Prüfung des besuchten Pfads = präzise Zyklusvermeidung; CYCLE-Klausel = native Erkennung in modernen Engines.
SQL Servers MAXRECURSION 100 ist ein impliziter Sicherheitsmechanismus — entfernen Sie ihn nicht ohne eine andere Absicherung.
Die Verknüpfungsspalte indizieren und den Ausgangsbereich für eine bessere Performance eng begrenzen.

Sie können nun rekursive CTEs durchgängig schreiben, durchlaufen, erzeugen und absichern.

Häufig gestellte Fragen

Ist die Lektion „Unendliche Rekursion vermeiden“ kostenlos?

Ja — der vollständige Text von „Unendliche Rekursion vermeiden“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des SQL Interview Prep-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der SQL Interview Prep-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Unendliche Rekursion vermeiden“?

Zykluserkennung, Tiefenbegrenzungen und die Rekursionssicherung, nach der jeder Interviewer fragt Du übst SQL Interview Prep mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um SQL Interview Prep zu starten?

Keine Vorkenntnisse erforderlich. SQL Interview Prep auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Unendliche Rekursion vermeiden“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser SQL Interview Prep-Lektion Code schreiben und ausführen?

Ja. Jede SQL Interview Prep-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

← Zurück zu SQL Interview Prep