Warum haben einige von sys.dm_exec_query_profiles zurückgegebene Zeilen "???" für den physischen Operatornamen?

In SQL Server 2014 wurde die DMV sys.dm_exec_query_profiles eingeführt, mit der der Fortschritt der Ausführung von Abfragen in Echtzeit überwacht werden kann. Kürzlich habe ich mir eine etwas komplexe Abfrage in SQL Server 2016 SP1 angesehen und festgestellt, dass sys.dm_exec_query_profilessie zusätzliche Knoten enthält, die im Abfrageplan nicht vorhanden sind. Diese Knoten hatten ???für die physical_operator_name:

Für die parallele Version der Abfrage gab es nur einen versteckten Knoten. Dem Knoten war eine object_idmit der inneren Tabelle eines verschachtelten Loop-Joins verknüpft. Nach dem node_idhier sollte der Knoten erschienen sein:

Das Ausführen der Abfrage mit MAXDOP 1führte zu einigen weiteren versteckten Knoten. Der ???Knoten wurde an derselben Stelle wie zuvor angezeigt:

Es gab auch einen neuen, der nicht im Parallelplan enthalten war:

Diese scheinen nur um einige verschachtelte Schleifenverknüpfungen herum zu erscheinen. Ich kann mich nicht erinnern, dieses Verhalten unter SQL Server 2014 gesehen zu haben. Leider ist die Abfrage komplex und ich kann keinen anonymisierten Plan hochladen.

Was ist denn hier los? Warum werden sys.dm_exec_query_profileszusätzliche Abfrageplanknoten gemeldet, die nicht im grafischen Plan angezeigt werden?

Stapelmodusadapter (Stellen in einem Abfrageplan, an denen die Zeilenverarbeitung auf Stapelverarbeitung umschaltet oder umgekehrt) werden wie ???in der DMV mit thread_id0 angezeigt. Die Beispielabfrage verwendet jedoch keine Stapelverarbeitung, sodass dies nicht der Fall ist die Ursache hier.

Das Vorabrufen verschachtelter Schleifen kann auch dafür verantwortlich sein, dass zusätzliche Zeilen in angezeigt werden sys.dm_exec_query_profiles. Es gibt ein dokumentiertes Trace-Flag zum Deaktivieren des Vorabrufs verschachtelter Schleifen:

Das Ablaufverfolgungsflag 8744 deaktiviert das Vorabrufen für den Operator "Verschachtelte Schleifen".

Die falsche Verwendung dieses Ablaufverfolgungsflags kann zu zusätzlichen physischen Lesevorgängen führen, wenn SQL Server Pläne ausführt, die den Operator "Verschachtelte Schleifen" enthalten. Weitere Informationen zum Operator "Verschachtelte Schleifen" finden Sie im Thema "Referenz zu logischen und physischen Operatoren" in SQL Server 2005 Books Online.

Wenn ich QUERYTRACEON 8744der Abfrage einen Abfragehinweis hinzufüge , werden die ???Knoten nicht mehr angezeigt.

Für ein reproduzierbares Beispiel für das Vorabrufen verschachtelter Schleifen werde ich Paul Whites Beispiel gegen Adventure Works aus seinem Artikel zum Vorabrufen verschachtelter Schleifen ausleihen :

SELECT TOP (1000)
    P.Name,
    TH.TransactionID
FROM Production.Product AS P
JOIN Production.TransactionHistory AS TH
    ON TH.ProductID = P.ProductID
WHERE
    P.Name LIKE N'[K-P]%'
ORDER BY 
    P.Name, 
    TH.TransactionID;

Wenn ich diese Abfrage für SQL Server 2016 SP1 ausführe und die Ausgabe von schnell sys.dm_exec_query_profileserhalte, erhalte ich die folgenden Ergebnisse:

╔════════════════════╦════════════════════════╦═════════╦═══════════╗
║    OBJECT_NAME     ║ physical_operator_name ║ node_id ║ thread_id ║
╠════════════════════╬════════════════════════╬═════════╬═══════════╣
║ NULL               ║ Top                    ║       0 ║         0 ║
║ NULL               ║ Nested Loops           ║       1 ║         0 ║
║ TransactionHistory ║ ???                    ║       2 ║         0 ║
║ Product            ║ Index Seek             ║       3 ║         0 ║
║ TransactionHistory ║ Index Seek             ║       4 ║         0 ║
╚════════════════════╩════════════════════════╩═════════╩═══════════╝

Wenn ich dieselbe Abfrage in SQL Server 2014 ausführe, erhalte ich folgende Ergebnisse:

╔════════════════════╦════════════════════════╦═════════╦═══════════╗
║    OBJECT_NAME     ║ physical_operator_name ║ node_id ║ thread_id ║
╠════════════════════╬════════════════════════╬═════════╬═══════════╣
║ NULL               ║ Top                    ║       0 ║         0 ║
║ NULL               ║ Nested Loops           ║       1 ║         0 ║
║ Product            ║ Index Seek             ║       3 ║         0 ║
║ TransactionHistory ║ Index Seek             ║       4 ║         0 ║
╚════════════════════╩════════════════════════╩═════════╩═══════════╝

In beiden Fällen erfolgt die Vorabrufoptimierung für verschachtelte Schleifen. Es scheint jedoch, dass nur SQL Server 2016 dies meldet, was erklären könnte, warum ich dies in SQL Server 2014 noch nie gesehen habe.