この派生テーブルがパフォーマンスを改善するのはなぜですか？

json文字列をパラメーターとして受け取るクエリがあります。jsonは、緯度と経度のペアの配列です。入力例は次のとおりです。

declare @json nvarchar(max)= N'[[40.7592024,-73.9771259],[40.7126492,-74.0120867]
,[41.8662374,-87.6908788],[37.784873,-122.4056546]]';

それは、1,3,5,10マイルの距離で、地理的なポイントの周りのPOIの数を計算するTVFを呼び出します。

create or alter function [dbo].[fn_poi_in_dist](@geo geography)
returns table
with schemabinding as
return 
select count_1  = sum(iif(LatLong.STDistance(@geo) <= 1609.344e * 1,1,0e))
      ,count_3  = sum(iif(LatLong.STDistance(@geo) <= 1609.344e * 3,1,0e))
      ,count_5  = sum(iif(LatLong.STDistance(@geo) <= 1609.344e * 5,1,0e))
      ,count_10 = count(*)
from dbo.point_of_interest
where LatLong.STDistance(@geo) <= 1609.344e * 10

jsonクエリの目的は、この関数を一括呼び出しすることです。このように呼び出すと、パフォーマンスは非常に低く、わずか4ポイントで10秒近くかかります。

select row=[key]
      ,count_1
      ,count_3
      ,count_5
      ,count_10
from openjson(@json)
cross apply dbo.fn_poi_in_dist(
            geography::Point(
                convert(float,json_value(value,'$[0]'))
               ,convert(float,json_value(value,'$[1]'))
               ,4326))

計画= https://www.brentozar.com/pastetheplan/?id=HJDCYd_o4

ただし、派生テーブル内で地理の構成を移動すると、パフォーマンスが大幅に向上し、クエリが約1秒で完了します。

select row=[key]
      ,count_1
      ,count_3
      ,count_5
      ,count_10
from (
select [key]
      ,geo = geography::Point(
                convert(float,json_value(value,'$[0]'))
               ,convert(float,json_value(value,'$[1]'))
               ,4326)
from openjson(@json)
) a
cross apply dbo.fn_poi_in_dist(geo)

計画= https://www.brentozar.com/pastetheplan/?id=HkSS5_OoE

計画は実質的に同一に見えます。どちらも並列処理を使用せず、両方とも空間インデックスを使用します。スロープランには、ヒントで削除できる追加の遅延スプールがありoption(no_performance_spool)ます。ただし、クエリのパフォーマンスは変わりません。まだずっと遅いままです。

追加されたヒントを使用して両方をバッチで実行すると、両方のクエリの重みが等しくなります。

SQLサーバーのバージョン= Microsoft SQL Server 2016（SP1-CU7-GDR）（KB4057119）-13.0.4466.4（X64）

私の質問は、なぜこれが重要なのですか？派生テーブル内の値を計算する必要があるかどうかを知るにはどうすればよいですか？

パフォーマンスの違いが見られる理由を説明する部分的な答えを与えることができます-それでもいくつかの未解決の質問が残っています（SQL Serverは、式を列として投影する中間テーブル式を導入せずに、より最適なプランを作成できますか？）

違いは、高速プランでは、JSON配列要素を解析してGeographyを作成するために必要な作業が4回行われるopenjsonことです（関数から出力される各行に対して1回）- 低速プランでは100,000 回以上行われます。

高速計画では...

geography::Point(
                convert(float,json_value(value,'$[0]'))
               ,convert(float,json_value(value,'$[1]'))
               ,4326)

関数のExpr1000左側の計算スカラーで割り当てられopenjsonます。これgeoは、派生テーブルの定義に対応します。

高速プランでは、フィルターとストリームの集約参照Expr1000。遅い計画では、基礎となる完全な表現を参照します。

ストリーム集約プロパティ

フィルターは116,995回実行され、各実行には式の評価が必要です。ストリーム集約には、集約のために110,520行が流れ、この式を使用して3つの個別の集約を作成します。110,520 * 3 + 116,995 = 448,555。個々の評価に18マイクロ秒かかったとしても、クエリ全体でさらに8秒の時間がかかります。

この効果は、プランXMLの実際の時間統計で確認できます（遅いプランの場合は赤で、速いプランの場合は青で、時間はミリ秒で示されます）。

ストリーム集合体は、その直接の子よりも6.209秒長い経過時間を持っています。そして、子時間の大部分はフィルターによって占められました。これは、余分な式の評価に対応します。

ちなみに...一般に、ラベルのような基になる式が一度だけ計算され、再評価されないことは確かではありませんExpr1000が、この場合は実行タイミングの不一致から明らかになります。