Zeichenfolgenaggregation im Laufe der Jahre in SQL Server

Seit SQL Server 2005 gibt es den Trick, FOR XML PATH zu verwenden Zeichenfolgen zu denormalisieren und sie zu einer einzigen (normalerweise durch Kommas getrennten) Liste zusammenzufassen, war sehr beliebt. In SQL Server 2017 jedoch STRING_AGG() beantwortete endlich langjährige und weit verbreitete Bitten der Community, GROUP_CONCAT() zu simulieren und ähnliche Funktionen, die in anderen Plattformen zu finden sind. Ich habe vor kurzem begonnen, viele meiner Stack Overflow-Antworten mit der alten Methode zu ändern, sowohl um den vorhandenen Code zu verbessern als auch um ein zusätzliches Beispiel hinzuzufügen, das besser für moderne Versionen geeignet ist.

Ich war etwas entsetzt über das, was ich vorfand.

Bei mehr als einer Gelegenheit musste ich überprüfen, ob der Code überhaupt meiner war.

Ein kurzes Beispiel

Schauen wir uns eine einfache Demonstration des Problems an. Jemand hat eine Tabelle wie diese:

CREATE TABLE dbo.FavoriteBands
(
  UserID   int,
  BandName nvarchar(255)
);
 
INSERT dbo.FavoriteBands
(
  UserID, 
  BandName
) 
VALUES
  (1, N'Pink Floyd'), (1, N'New Order'), (1, N'The Hip'),
  (2, N'Zamfir'),     (2, N'ABBA');

Auf der Seite mit den Lieblingsbands jedes Benutzers soll die Ausgabe so aussehen:

UserID   Bands
------   ---------------------------------------
1        Pink Floyd, New Order, The Hip
2        Zamfir, ABBA

In den Tagen von SQL Server 2005 hätte ich diese Lösung angeboten:

SELECT DISTINCT UserID, Bands = 
      (SELECT BandName + ', '
         FROM dbo.FavoriteBands
         WHERE UserID = fb.UserID
         FOR XML PATH('')) 
FROM dbo.FavoriteBands AS fb;

Aber wenn ich jetzt auf diesen Code zurückblicke, sehe ich viele Probleme, denen ich nicht widerstehen kann, sie zu beheben.

MATERIAL

Der schwerwiegendste Fehler im obigen Code ist, dass er ein nachgestelltes Komma hinterlässt:

UserID   Bands
------   ---------------------------------------
1        Pink Floyd, New Order, The Hip, 
2        Zamfir, ABBA, 

Um dies zu lösen, sehe ich oft Leute, die die Abfrage in eine andere packen und dann die Bänder umgeben Ausgabe mit LEFT(Bands, LEN(Bands)-1) . Dies ist jedoch eine unnötige zusätzliche Berechnung; Stattdessen können wir das Komma an den Anfang des Strings verschieben und die ersten ein oder zwei Zeichen mit STUFF entfernen . Dann müssen wir die Länge der Zeichenfolge nicht berechnen, da sie irrelevant ist.

SELECT DISTINCT UserID, Bands = STUFF(
--------------------------------^^^^^^
      (SELECT ', ' + BandName
--------------^^^^^^
         FROM dbo.FavoriteBands
         WHERE UserID = fb.UserID
         FOR XML PATH('')), 1, 2, '')
--------------------------^^^^^^^^^^^
FROM dbo.FavoriteBands AS fb;

Sie können dies weiter anpassen, wenn Sie ein längeres oder bedingtes Trennzeichen verwenden.

UNTERSCHIEDLICH

Das nächste Problem ist die Verwendung von DISTINCT . Der Code funktioniert so, dass die abgeleitete Tabelle eine durch Kommas getrennte Liste für jede UserID generiert Wert, dann werden die Duplikate entfernt. Wir können dies sehen, wenn wir uns den Plan ansehen und sehen, dass der XML-bezogene Operator siebenmal ausgeführt wird, obwohl letztendlich nur drei Zeilen zurückgegeben werden:

Abbildung 1:Plan, der den Filter nach der Aggregation zeigt

Wenn wir den Code ändern, um GROUP BY zu verwenden statt DISTINCT :

SELECT /* DISTINCT */ UserID, Bands = STUFF(
      (SELECT ', ' + BandName
         FROM dbo.FavoriteBands
         WHERE UserID = fb.UserID
         FOR XML PATH('')), 1, 2, '')
  FROM dbo.FavoriteBands AS fb
  GROUP BY UserID;
--^^^^^^^^^^^^^^^

Es ist ein subtiler Unterschied und ändert nichts an den Ergebnissen, aber wir können sehen, dass sich der Plan verbessert. Grundsätzlich werden die XML-Operationen zurückgestellt, bis die Duplikate entfernt wurden:

Abbildung 2:Plan zeigt den Filter vor der Aggregation

Auf dieser Skala ist der Unterschied unerheblich. Aber was ist, wenn wir weitere Daten hinzufügen? Auf meinem System fügt dies etwas mehr als 11.000 Zeilen hinzu:

INSERT dbo.FavoriteBands(UserID, BandName)
  SELECT [object_id], name FROM sys.all_columns;

Wenn wir die beiden Abfragen erneut ausführen, sind die Unterschiede in Dauer und CPU sofort offensichtlich:

Abbildung 3:Laufzeitergebnisse beim Vergleich von DISTINCT und GROUP BY

Aber auch andere Nebenwirkungen sind in den Plänen offensichtlich. Im Fall von DISTINCT , die UDX wird erneut für jede Zeile in der Tabelle ausgeführt, es gibt einen übermäßig eifrigen Index-Spool, es gibt eine eindeutige Sortierung (bei mir immer eine rote Flagge) und die Abfrage hat eine hohe Speicherzuweisung, was die Parallelität ernsthaft beeinträchtigen kann :

Abbildung 4:DISTINCT-Plan im Maßstab

In der Zwischenzeit im GROUP BY -Abfrage wird die UDX nur einmal für jede eindeutige UserID ausgeführt , die eifrige Spule liest eine viel geringere Anzahl von Zeilen, es gibt keinen eindeutigen Sortieroperator (er wurde durch einen Hash-Match ersetzt) ​​und die Speicherzuteilung ist im Vergleich dazu winzig:

Abbildung 5:GROUP BY-Plan im Maßstab

Es dauert eine Weile, um zurückzugehen und alten Code wie diesen zu reparieren, aber seit einiger Zeit bin ich sehr reglementiert, wenn es darum geht, immer GROUP BY zu verwenden statt DISTINCT .

N-Präfix

Zu viele alte Codebeispiele, auf die ich gestoßen bin, gingen davon aus, dass niemals Unicode-Zeichen verwendet werden würden, oder zumindest deuteten die Beispieldaten nicht auf diese Möglichkeit hin. Ich würde meine Lösung wie oben anbieten, und dann würde der Benutzer zurückkommen und sagen:„Aber in einer Zeile habe ich 'просто красный' , und es kommt zurück als '?????? ???????' !” Ich erinnere die Leute oft daran, dass sie potenziellen Unicode-String-Literalen immer das Präfix N voranstellen müssen, es sei denn, sie wissen absolut, dass sie es immer nur mit varchar zu tun haben werden Zeichenfolgen oder ganze Zahlen. Ich fing an, sehr explizit und wahrscheinlich sogar übervorsichtig zu sein:

SELECT UserID, Bands = STUFF(
      (SELECT N', ' + BandName
--------------^
         FROM dbo.FavoriteBands
         WHERE UserID = fb.UserID
         FOR XML PATH(N'')), 1, 2, N'')
----------------------^ -----------^
  FROM dbo.FavoriteBands AS fb
  GROUP BY UserID;

XML-Entitierung

Ein weiteres „Was wäre wenn?“ Szenario, das in den Beispieldaten eines Benutzers nicht immer vorhanden ist, sind XML-Zeichen. Was wäre zum Beispiel, wenn meine Lieblingsband „Bob &Sheila <> Strawberries“ heißt “? Die Ausgabe mit der obigen Abfrage wird XML-sicher gemacht, was wir nicht immer wollen (z. B. Bob & Sheila <> Strawberries ). Google-Suchanfragen schlugen damals vor, „Sie müssen TYPE hinzufügen “, und ich erinnere mich, dass ich so etwas versucht habe:

SELECT UserID, Bands = STUFF(
      (SELECT N', ' + BandName
         FROM dbo.FavoriteBands
         WHERE UserID = fb.UserID
         FOR XML PATH(N''), TYPE), 1, 2, N'')
--------------------------^^^^^^
  FROM dbo.FavoriteBands AS fb
  GROUP BY UserID;

Leider ist der Ausgabedatentyp der Unterabfrage in diesem Fall xml . Dies führt zu folgender Fehlermeldung:

Sie müssen SQL Server mitteilen, dass Sie den resultierenden Wert als Zeichenfolge extrahieren möchten, indem Sie den Datentyp und das erste Element angeben. Damals würde ich das wie folgt hinzufügen:

SELECT UserID, Bands = STUFF(
      (SELECT N', ' + BandName
         FROM dbo.FavoriteBands
         WHERE UserID = fb.UserID
         FOR XML PATH(N''), TYPE).value(N'.', N'nvarchar(max)'), 
--------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
           1, 2, N'')
  FROM dbo.FavoriteBands AS fb
  GROUP BY UserID;

Dies würde die Zeichenfolge ohne XML-Entität zurückgeben. Aber ist es das effizienteste? Letztes Jahr erinnerte mich Charlieface daran, dass Mister Magoo einige umfangreiche Tests durchgeführt und ./text()[1] gefunden hatte war schneller als die anderen (kürzeren) Ansätze wie . und .[1][code> . (Ich habe dies ursprünglich aus einem Kommentar gehört, den Mikael Eriksson hier für mich hinterlassen hat.) Ich habe meinen Code noch einmal so angepasst, dass er so aussieht:

SELECT UserID, Bands = STUFF(
      (SELECT N', ' + BandName
         FROM dbo.FavoriteBands
         WHERE UserID = fb.UserID
         FOR XML PATH(N''), TYPE).value(N'./text()[1]', N'nvarchar(max)'), 
------------------------------------------^^^^^^^^^^^
           1, 2, N'')
  FROM dbo.FavoriteBands AS fb
  GROUP BY UserID;

SELECT UserID, Bands = STUFF(
      (SELECT N', ' + BandName
         FROM dbo.FavoriteBands
         WHERE UserID = fb.UserID
         ORDER BY BandName
---------^^^^^^^^^^^^^^^^^
         FOR XML PATH(N''),
          TYPE).value(N'./text()[1]', N'nvarchar(max)'), 1, 2, N'')
  FROM dbo.FavoriteBands AS fb
  GROUP BY UserID;

SELECT UserID, Bands = STRING_AGG(BandName, N', ')
  FROM dbo.FavoriteBands
  GROUP BY UserID;

SELECT UserID, Bands = STRING_AGG(BandName, N', ')
    WITHIN GROUP (ORDER BY BandName)
----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  FROM dbo.FavoriteBands
  GROUP BY UserID;

CREATE INDEX ix_FavoriteBands ON dbo.FavoriteBands(UserID, BandName);

SELECT UserID, 
       Bands = STRING_AGG(CONVERT(nvarchar(max), BandName), N', ')
--------------------------^^^^^^^^^^^^^^^^^^^^^^
  FROM dbo.FavoriteBands
  GROUP BY UserID;