Verkettung Physische Operation: Garantiert sie die Ausführungsreihenfolge?

In Standard-SQL kann union allnicht garantiert werden , dass das Ergebnis von a in einer beliebigen Reihenfolge vorliegt. So etwas wie:

select 'A' as c union all select 'B'

Könnte zwei Zeilen in beliebiger Reihenfolge zurückgeben (obwohl in der Praxis in jeder mir bekannten Datenbank "A" vor "B" steht).

In SQL Server wird daraus ein Ausführungsplan mit einer physischen Operation "Verkettung".

Ich könnte mir leicht vorstellen, dass die Verkettungsoperation ihre Eingaben scannt und alle verfügbaren Eingaben zurückgibt. Im Internet fand ich jedoch die folgende Aussage ( hier ):

Der Abfrageprozessor führt diesen Plan in der Reihenfolge aus, in der die Operatoren im Plan angezeigt werden, wobei der erste der oberste und der letzte der letzte der letzte ist.

Frage: Stimmt das in der Praxis? Ist dies garantiert wahr?

Ich habe in der Microsoft-Dokumentation keinen Hinweis gefunden, dass die Eingaben von der ersten bis zur letzten nacheinander durchsucht werden. Wenn ich dagegen versuche, es auszuführen, deuten die Ergebnisse darauf hin, dass die Eingaben tatsächlich in der richtigen Reihenfolge verarbeitet werden.

Gibt es eine Möglichkeit, die Engine mehr als eine Eingabe gleichzeitig verarbeiten zu lassen? Meine Tests (die viel kompliziertere Ausdrücke als Konstanten verwenden) laufen auf einem parallelen 8-Core-Rechner, und die meisten Abfragen nutzen die Parallelität.

Nein , es gibt keine Dokumentation von Microsoft, die das Verhalten garantiert . Daher wird keine Garantie übernommen .

Vorausgesetzt, der Simple Talk-Artikel ist korrekt und der physische Operator Verkettung verarbeitet Eingaben immer in der Reihenfolge, die im Plan angegeben ist (sehr wahrscheinlich ist dies der Fall), und es wird nicht garantiert, dass SQL Server immer Pläne generiert, die dieselben beibehalten Bei der Reihenfolge zwischen dem Abfragetext und dem Abfrageplan sind Sie nur geringfügig besser dran.

Wir können dies jedoch weiter untersuchen. Wenn das Abfrageoptimierungsprogramm die Verkettungsoperatoreingabe neu anordnen konnte, sollten Zeilen in der undokumentierten DMV vorhanden sein, sys.dm_exec_query_transformation_statsdie dieser Optimierung entsprechen.

SELECT * FROM sys.dm_exec_query_transformation_stats 
    WHERE name LIKE '%CON%' OR name LIKE '%UNIA%'

In SQL Server 2012 Enterprise Edition werden 24 Zeilen erstellt. Ignoriert man die falschen Übereinstimmungen für Umwandlungen, die sich auf Konstanten beziehen, gibt es eine Umwandlung, die sich auf den physischen Verknüpfungsoperator UNIAtoCON(Union All to Concatenation) bezieht . Auf der Ebene des physischen Operators wird ein Verkettungsoperator, der einmal ausgewählt wurde, in der Reihenfolge des Operators verarbeitet, aus dem er abgeleitet wurde.

Tatsächlich ist das nicht ganz richtig. Nach der Optimierung gibt es Umschreibungen, mit denen die Eingaben für einen physischen Verkettungsoperator nach Abschluss der kostenbasierten Optimierung neu angeordnet werden können. Ein Beispiel tritt auf, wenn die Verkettung einem Zeilenziel unterliegt (daher ist es möglicherweise wichtig, zuerst von der billigeren Eingabe zu lesen). Weitere Informationen finden Sie unter UNION ALLOptimierung von Paul White.

Diese späte physische Umschreibung war bis einschließlich SQL Server 2008 R2 funktionsfähig, aber eine Regression bedeutete, dass sie nicht mehr auf SQL Server 2012 und höher angewendet wurde. Es wurde ein Fix veröffentlicht , mit dem dieses Neuschreiben für SQL Server 2014 und höher (nicht 2012) mit aktivierten Hotfixes für das Abfrageoptimierungsprogramm wiederhergestellt wird (z. B. Ablaufverfolgungsflag 4199).

Aber über den Logical Union All Operator ( UNIA)? Es gibt eine UNIAReorderInputsTransformation, die die Eingaben neu anordnen kann. Es gibt auch zwei physische Operatoren, die zum Implementieren einer logischen Union All UNIAtoCONund UNIAtoMERGE(Union All to Merge Union) verwendet werden können.

Aus diesem Grund kann das Abfrageoptimierungsprogramm die Eingaben für a neu anordnen UNION ALL. Es scheint sich jedoch nicht um eine allgemeine Transformation zu handeln (keine Verwendung von UNIAReorderInputsauf den SQL-Servern, auf die ich problemlos zugreifen kann. Wir kennen die Umstände nicht, unter denen das Optimierungsprogramm verwendet werden würde UNIAReorderInputs. Es wird jedoch auf jeden Fall verwendet, wenn ein Plan erstellt oder verwendet wird Der Planhinweis wird verwendet, um einen Plan zu erzwingen, der unter Verwendung der oben erwähnten physisch neu geordneten Eingaben für das Zeilenziel generiert wird.

Gibt es eine Möglichkeit, die Engine mehr als eine Eingabe gleichzeitig verarbeiten zu lassen?

Der physikalische Operator Verkettung kann in einem parallelen Abschnitt eines Plans vorhanden sein. Mit einigen Schwierigkeiten konnte ich mit der folgenden Abfrage einen Plan mit parallelen Verkettungen erstellen:

SELECT userid, regdate  FROM (  --Users table is around 3mil rows
    SELECT  userid, RegDate FROM users WHERE userid > 1000000
    UNION 
    SELECT  userid, RegDate FROM users WHERE userid < 1000000
    UNION all
    SELECT userid, RegDate FROM users WHERE userid < 2000000
    ) d ORDER BY RegDate OPTION (RECOMPILE)

Im engeren Sinne scheint der physikalische Verkettungsoperator also Eingaben immer auf konsistente Weise zu verarbeiten (oberste zuerst, unterste Sekunde); Das Optimierungsprogramm kann jedoch die Reihenfolge der Eingaben ändern, bevor der physische Operator ausgewählt wird, oder eine Zusammenführungsvereinigung anstelle einer Verkettung verwenden.

Laut Craig Freedman ist die Ausführungsreihenfolge für den Verkettungsoperator garantiert.

In seinem Blogbeitrag Anzeigen von Abfrageplänen in MSDN-Blogs:

Beachten Sie, dass die Reihenfolge der Kinder wichtig ist, wenn ein Operator mehr als ein Kind hat. Das oberste Kind ist das erste Kind, während das unterste Kind das zweite ist. Der Verkettungsoperator verarbeitet die untergeordneten Elemente in dieser Reihenfolge.

Und aus Online-Büchern der Showplan Logical and Physical Operators Reference

Der physikalische Operator Verkettung verfügt über zwei oder mehr Eingaben und eine Ausgabe. Die Verkettung kopiert Zeilen vom ersten Eingabestream in den Ausgabestream und wiederholt diese Operation für jeden weiteren Eingabestream.

_{Community Wiki Antwort :}

Ich weiß nicht, ob Sie nachweisen können, dass ein beobachtetes Verhalten immer garantiert ist, es sei denn, Sie können ein Gegenbeispiel anfertigen. Wenn dies nicht der Fall ist, können Sie natürlich die Reihenfolge festlegen, in der die Ergebnisse zurückgegeben werden, indem Sie eine hinzufügen ORDER BY.

Ich weiß nicht, ob ein "Fix" vorliegt oder ob ein Fix erforderlich ist, wenn Sie nachweisen können, dass die Abfragen in einigen Szenarien in einer anderen Reihenfolge verarbeitet werden.

Das Fehlen einer expliziten offiziellen Dokumentation legt mir nahe, dass Sie sich nicht darauf verlassen sollten. Dies ist genau die Art von Dingen, mit denen Menschen in ORDER BYeiner Ansicht in Schwierigkeiten geraten sind und GROUP BYohneORDER BY , vor 8 Jahren , wenn SQL Server 2005 des Optimierers veröffentlicht wurde.

Selbst wenn Sie der Meinung sind, dass Sie heute ein bestimmtes Verhalten garantieren können, würde ich bei all den neuen Funktionen in den neueren Versionen von SQL Server nicht erwarten, dass dies zutrifft (bis dies dokumentiert ist).

Was werden Sie mit den Ergebnissen tun, auch wenn Sie nicht von diesem Verhalten abhängig sind? Wie auch immer, ich würde nicht eine einfache Diskussion Artikel von einem Außenstehenden nennen offiziellen . Soweit wir wissen, ist dies nur eine Vermutung, die auf Beobachtung beruht.

Microsoft wird niemals offizielle Dokumente veröffentlichen, in denen angegeben wird, dass "x" nicht garantiert "y" ist. Dies ist einer der Gründe, warum wir noch fast ein Jahrzehnt später Probleme haben, Menschen davon zu überzeugen, dass sie sich nicht auf eingehaltene Bestellungen verlassen können ORDER BY- es gibt keine Dokumentation, die besagt, dass "dies nicht garantiert ist".