SQL Server v.Next：STRING_AGG（）のパフォーマンス

INSERT dbo.Objects([object_id], [object_name]) -- 656 rows
  SELECT [object_id], QUOTENAME(s.name) + N'.' + QUOTENAME(o.name) 
    FROM sys.all_objects AS o
    INNER JOIN sys.schemas AS s 
    ON o.[schema_id] = s.[schema_id]
    WHERE EXISTS
    (
      SELECT 1 FROM sys.all_columns 
      WHERE [object_id] = o.[object_id]
    );
 
INSERT dbo.Columns([object_id], column_name) -- 8,085 rows 
  SELECT [object_id], name 
    FROM sys.all_columns AS c  
    WHERE EXISTS
    (
      SELECT 1 FROM dbo.Objects 
      WHERE [object_id] = c.[object_id]
    );

私のシステムでは、これにより656個のオブジェクトと8,085個の列が生成されました（システムによって生成される数はわずかに異なる場合があります）。

計画

まず、プランエクスプローラーを使用して、2つの順序付けされていないクエリのプランと[テーブルI/O]タブを比較してみましょう。全体的なランタイムメトリックは次のとおりです。

XML PATH（上）とSTRING_AGG（）（下）のランタイムメトリック

FOR XML PATHからのグラフィカルプランとテーブルI/O クエリ：

プランとテーブルI / O XML PATHの場合、順序なし

そしてSTRING_AGGから バージョン：

プランとテーブルI / O STRING_AGGの場合、順序付けなし

後者の場合、クラスター化されたインデックスシークは私には少し厄介なようです。これは、めったに使用されない FORCESCANをテストするための良いケースのように思われました。 ヒント（いいえ、これは FOR XML PATHの助けにはなりません。 クエリ）：

SELECT [object]  = o.[object_name],
       [columns] = STRING_AGG(c.column_name, N',')
FROM dbo.Objects AS o
INNER JOIN dbo.Columns AS c WITH (FORCESCAN) -- added hint
ON o.[object_id] = c.[object_id]
GROUP BY o.[object_name];

これで、プランとテーブルI/Oタブがロットになります。 少なくとも一見したところ、より良い：

プランとテーブルI / O STRING_AGG（）の場合、順序付けなし、FORCESCANを使用

クエリの順序付けされたバージョンは、ほぼ同じ計画を生成します。 FOR XML PATHの場合 バージョン、並べ替えが追加されます：

FORXMLPATHバージョンに並べ替えを追加

STRING_AGG（）の場合 、この場合、 FORCESCAN がなくても、スキャンが選択されます。 ヒントであり、追加の並べ替え操作は必要ありません。したがって、プランは FORCESCANと同じように見えます。 バージョン。

大規模

計画と1回限りの実行時メトリックを見ると、 STRING_AGG（）かどうかについてのアイデアが得られる可能性があります。 既存のFORXML PATHよりもパフォーマンスが優れています 解決策ですが、テストが大きいほど理にかなっている場合があります。グループ化された連結を5,000回実行するとどうなりますか？

SELECT SYSDATETIME();
GO
 
DECLARE @x nvarchar(max);
SELECT @x = STRING_AGG(c.column_name, N',')
  FROM dbo.Objects AS o
  INNER JOIN dbo.Columns AS c
  ON o.[object_id] = c.[object_id]
  GROUP BY o.[object_name];
GO 5000
SELECT [string_agg, unordered] = SYSDATETIME();
GO
 
DECLARE @x nvarchar(max);
SELECT @x = STRING_AGG(c.column_name, N',')
  FROM dbo.Objects AS o
  INNER JOIN dbo.Columns AS c WITH (FORCESCAN)
  ON o.[object_id] = c.[object_id]
  GROUP BY o.[object_name];
GO 5000
SELECT [string_agg, unordered, forcescan] = SYSDATETIME();
 
GO
DECLARE @x nvarchar(max);
SELECT @x = STUFF((SELECT N',' +c.column_name
  FROM dbo.Columns AS c
  WHERE c.[object_id] = o.[object_id]
  FOR XML PATH, TYPE).value(N'.[1]',N'nvarchar(max)'),1,1,N'')
FROM dbo.Objects AS o;
GO 5000
SELECT [for xml path, unordered] = SYSDATETIME();
 
GO
DECLARE @x nvarchar(max);
SELECT @x = STRING_AGG(c.column_name, N',')
  WITHIN GROUP (ORDER BY c.column_name)
  FROM dbo.Objects AS o
  INNER JOIN dbo.Columns AS c
  ON o.[object_id] = c.[object_id]
  GROUP BY o.[object_name];
GO 5000
SELECT [string_agg, ordered] = SYSDATETIME();
 
GO
DECLARE @x nvarchar(max);
SELECT @x = STUFF((SELECT N',' +c.column_name
  FROM dbo.Columns AS c
  WHERE c.[object_id] = o.[object_id]
  ORDER BY c.column_name
  FOR XML PATH, TYPE).value(N'.[1]',N'nvarchar(max)'),1,1,N'')
FROM dbo.Objects AS o
ORDER BY o.[object_name];
GO 5000
SELECT [for xml path, ordered] = SYSDATETIME();

このスクリプトを5回実行した後、期間の数値を平均しました。結果は次のとおりです。

さまざまなグループ化された連結アプローチの期間（ミリ秒）

FORCESCAN ヒントは実際に事態を悪化させました。コストをクラスター化されたインデックスシークからシフトしましたが、推定コストが比較的同等であると見なしたとしても、実際にはソートははるかに悪化しました。さらに重要なのは、 STRING_AGG（）であることがわかります。 連結された文字列を特定の方法で並べ替える必要があるかどうかに関係なく、パフォーマンス上の利点があります。 STRING_SPLIT（）と同様 、3月に振り返ったところ、この関数は「v1」よりもかなり前にスケーリングされていることに非常に感銘を受けました。

おそらく将来の投稿のために、さらにテストを計画しています：

• すべてのデータが単一のテーブルからのものであり、順序付けをサポートするインデックスがある場合とない場合
• Linuxでの同様のパフォーマンステスト

それまでの間、グループ化された連結の特定のユースケースがある場合は、以下で共有してください（または、abertrand @ sentryone.comに電子メールを送信してください）。私は自分のテストが可能な限り現実の世界であることを確認することに常にオープンです。