Ist es WIRKLICH möglich, dass die Reihenfolge für diese bestimmte redundante abgeleitete Tabelle nicht garantiert wird?

Ich bin auf diese Frage in einem Twitter-Gespräch mit Lukas Eder gestoßen .

Obwohl das richtige Verhalten darin besteht, die ORDER BY-Klausel auf die äußerste Abfrage anzuwenden, verwenden wir hier keine DISTINCT-, GROUP BY-, JOIN- oder andere WHERE-Klausel in der äußersten Abfrage. Warum sollte ein RDBMS nicht einfach die Klausel übergeben? eingehende Daten, wie sie nach der inneren Abfrage sortiert wurden?

SELECT * 
FROM (
    SELECT * FROM table ORDER BY time DESC
) AS t

Wenn Sie dieses Beispiel zumindest unter PostgreSQL ausführen, erhalten Sie denselben Ausführungsplan sowohl für die innere Abfrage als auch für dieses Beispiel für abgeleitete Tabellen sowie dieselbe Ergebnismenge.

Ich würde also davon ausgehen, dass der Planer die äußerste Abfrage einfach verwirft, weil sie redundant ist, oder einfach die Ergebnisse aus der inneren Tabelle durchläuft.

Glaubt jemand, dass dies möglicherweise nicht der Fall ist?

Die meisten Datenbanken sind sich ziemlich klar darüber, dass eine ORDER BYin einer Unterabfrage entweder:

• Nicht erlaubt: zB SQL Server, Sybase SQL Anywhere (sofern nicht mit TOPoder ergänzt OFFSET .. FETCH)
• Sinnlos: zB PostgreSQL, DB2 (wieder, sofern nicht mit OFFSET .. FETCHoder ergänzt LIMIT)

Hier ist ein Beispiel aus dem DB2 LUW-Handbuch (Schwerpunkt Mine)

Eine ORDER BY-Klausel in einer Unterauswahl hat keinen Einfluss auf die Reihenfolge der von einer Abfrage zurückgegebenen Zeilen . Eine ORDER BY-Klausel wirkt sich nur auf die Reihenfolge der zurückgegebenen Zeilen aus, wenn sie in der äußersten vollständigen Auswahl angegeben ist.

Der Wortlaut ist ziemlich explizit, genau wie bei PostgreSQL :

Wenn die Sortierung nicht ausgewählt ist, werden die Zeilen in einer nicht angegebenen Reihenfolge zurückgegeben. Die tatsächliche Reihenfolge hängt in diesem Fall von den Scan- und Join-Planarten und der Reihenfolge auf der Festplatte ab, darf jedoch nicht als zuverlässig angesehen werden . Eine bestimmte Ausgabereihenfolge kann nur garantiert werden, wenn der Sortierschritt explizit ausgewählt wird.

Aus dieser Spezifikation kann geschlossen werden, dass jede Reihenfolge, die sich aus der ORDER BYKlausel in einer abgeleiteten Tabelle ergibt, nur zufällig ist und zufällig mit Ihrer erwarteten Reihenfolge übereinstimmt (was in den meisten Datenbanken in Ihrem trivialen Beispiel der Fall ist), aber es wäre unklug, sich darauf zu verlassen Dies.

Randnotiz zu DB2:

Insbesondere hat DB2 eine weniger bekannte Funktion namensORDER BY ORDER OF <table-designator> , die wie folgt verwendet werden kann:

SELECT C1 FROM
   (SELECT C1 FROM T1
      UNION
    SELECT C1 FROM T2
    ORDER BY C1 ) AS UTABLE
ORDER BY ORDER OF UTABLE

In diesem speziellen Fall kann die Reihenfolge der abgeleiteten Tabelle im äußersten SELECT explizit wiederverwendet werden

Randnotiz zu Oracle:

In Oracle ist es seit Jahren üblich, die OFFSETPaginierung mithilfe von zu implementieren ROWNUM, die nur nach Bestellung einer abgeleiteten Tabelle angemessen berechnet werden kann :

SELECT *
FROM (
  SELECT rownum AS rn, t.* -- ROWNUM here depends on the derived table's ordering
  FROM (
    SELECT * FROM table ORDER BY time DESC
  ) t
) t
WHERE rn BETWEEN 10 AND 20

Es ist zu erwarten, dass ROWNUMzukünftige Oracle-Versionen zumindest bei Vorhandensein einer Abfrage dieses Verhalten nicht aufheben, um nicht so ziemlich das gesamte ältere Oracle SQL zu brechen, das noch nicht auf das viel wünschenswertere und umgestiegene Oracle SQL umgestellt wurde lesbare SQL-Standardsyntax OFFSET .. FETCH:

SELECT * FROM table ORDER BY time DESC OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY

Ja. Ohne eine ORDER BYKlausel ist die Ausgabereihenfolge undefiniert und der Abfrageplaner kann davon ausgehen, dass Sie dies wissen und verstehen.

Es kann sein, dass die äußere Abfrage, da sie keine Reihenfolge angibt, die Reihenfolge in der inneren Abfrage löschen kann, um eine Sortieroperation zu vermeiden, insbesondere wenn kein Clustered-Index oder überhaupt kein Index zur Unterstützung der Reihenfolge vorhanden ist. Wenn dies jetzt nicht der Fall ist , kann dies in zukünftigen Versionen der Fall sein.

Verlassen Sie sich niemals auf undefiniertes Verhalten. Wenn Sie eine bestimmte Bestellung benötigen, geben Sie an ORDER BYder entsprechenden Stelle eine Klausel an.

Es ist genau das Problem mit undefiniertem Verhalten - funktioniert für Sie, funktioniert für mich, formatiert die Festplatte in prod neu;)

Wir können einen Schritt zurücktreten und sagen, dass Sie in gewissem Sinne Recht haben - es gibt keinen irdischen Grund, warum ein vernünftiges RDBMS die Zeilen in der inneren Auswahl neu anordnen würde. Aber es ist nicht garantiert - was bedeutet, dass es in Zukunft einen Grund geben kann, und es steht den Anbietern frei, dies zu tun. Dies bedeutet, dass jeder Code, der sich auf dieses Verhalten stützt, einer Änderung ausgeliefert ist, die ein Anbieter vornehmen könnte und zu deren Veröffentlichung er nicht verpflichtet wäre, da es sich nicht um eine brechende Änderung eines API-POV handelt.

Ist es WIRKLICH möglich, dass die Reihenfolge für diese bestimmte redundante abgeleitete Tabelle nicht garantiert wird?

Die Antwort für alle derzeit vorhandenen Postgres- Versionen (die Sie getestet haben) lautet: Nein - für diese bestimmte Abfrage. Sortierreihenfolge ist garantiert.

SQL Server- ORDER BYBenutzer werden sich damit unwohl fühlen, da Microsoft Unterabfragen nicht einmal zulässt . Die Sortierreihenfolge ist für diese einfache Abfrage in Postgres dennoch garantiert. ORDER BYwird in der Unterabfrage angewendet, und die äußere Abfrage führt nichts aus, was die Reihenfolge ändern könnte.

Das Handbuch weist sogar im Kapitel Aggregatfunktionen darauf hin :

Alternativ funktioniert normalerweise die Angabe der Eingabewerte aus einer sortierten Unterabfrage.

Beachten Sie, dass dies nur zutrifft, wenn äußere Abfrageebenen keine Vorgänge hinzufügen, die die Reihenfolge ändern könnten. Es ist also nur für den einfachen Fall "garantiert" und wird nicht vom SQL-Standard unterstützt. Postgres kann nachbestellt werden, wenn zusätzliche Operationen möglich sind. Im Zweifelsfall fügen Sie ORDER BYdem Äußeren einen weiteren hinzu SELECT. (In diesem Fall wäre das innere ORDER BYRauschen für diese einfache Abfrage redundantes Rauschen.)