web-dev-qa-db-ja.com

計画内のCompute Scalar演算子に続く行推定が不正です

行の見積もりが実行計画のどこから来ているのかを理解するのに苦労しています。

プランのリンクを貼り付けます

declare
@BatchKey INT = 1, @ParentBatchKey INT = 1,
@QuoteRef varchar(50) = 'Q00018249',
@MpanRef varchar(50) = '1425431100004'


SELECT DISTINCT
        ISNULL(c.ContractReference,-1) AS [ContractReference] ,
        ISNULL(d_cd.ContractDetailsKey,-1) AS [ContractDetailsKey] ,
        -1 AccountManagerKey,
        -1 SegmentationKey,
        ISNULL(d_tpi.TpiKey,-1) AS [TpiKey] ,
        ISNULL(d_cu.CustomerKey,-1) AS [CustomerKey] ,
        ISNULL(d_p.ProductKey,-1) AS [ProductKey] ,
        -1 as PayPointKey,
        -1 AS [GspBandingKey], --Not used in Junifer ESOB
        ISNULL(d_pps.[ProductPricingStructureKey],-1) AS [ProductPricingStructureKey],
        ISNULL(d_tou.TouBandingKey,-1) AS [PricingStructureBandingKey],
        -1 AS [VolumePointCategoryKey],
        ISNULL(d_ppc.PowerPeriodCategoryKey,-1) AS [PowerPeriodCategoryKey],
        ISNULL(d_pcat.[PriceComponentAggregationTypeKey],-1) AS [PriceComponentAggregationTypeKey],
        -1 AS [MarginRateBandingKey], --Not used in Junifer ESOB
        -1 AS [DuosUrcBandingKey], --Not used in Junifer ESOB
        -1 AS [ConsumptionToleranceKey],
        ISNULL(d_mp.MeterPointKey,-1) AS [MeterPointKey] ,
        ISNULL(d.DateKey,-1) AS [ForecastDateKey] ,
        -1 AS [ForecastEFADateKey], 
        ISNULL(d_cw.DateKey,-1) AS [ContractWonDateKey] ,
        ISNULL(f.SiteVolumeKwh,0) AS [SiteVolume] ,
        ISNULL(f.GspVolumeKwh,0) AS [GspVolume] ,
        ISNULL(f.NbpVolumeKwh,0) AS [NbpVolume],
        @BatchKey,
        @ParentBatchKey,
        CAST(f.ForecastKey as NVARCHAR(100)) AS [SourceId]
FROM 
        [Electricity].[Forecast] f 
              INNER JOIN Electricity.ContractMeterPoint cmp ON cmp.MeterPointKey = f.MeterPointKey and cmp.ContractKey = f.ContractKey  
              INNER JOIN Electricity.Contract c on c.ContractKey = cmp.ContractKey 
        INNER JOIN Electricity.MeterPoint mp ON mp.MeterPointKey = cmp.MeterPointKey

        --INNER JOIN Electricity.ContractMeterPoint cmp ON cmp.MeterPointKey = mp.MeterPointKey and cmp.ContractKey = c.ContractKey 
        INNER JOIN Electricity.ProductBundle pb ON c.ProductBundleKey = pb.ProductBundleKey
        LEFT JOIN Electricity.Quote q ON c.QuoteKey = q.QuoteKey
        LEFT JOIN Gdf.Tender t ON q.TenderKey = t.TenderKey
        LEFT JOIN Gdf.Customer cu ON q.CustomerKey = cu.CustomerKey
        LEFT JOIN Electricity.ProductBundleAggregationType pbat ON pbat.ProductName = pb.BundleName
        LEFT JOIN Dimensional_DW.DimensionElectricity.Product d_p ON d_p.ProductDurableKey = pb.ProductBundleKey
        LEFT JOIN Dimensional_DW.Dimension.Tpi d_tpi ON d_tpi.TpiDurableKey = c.TpiKey
        LEFT JOIN Dimensional_DW.DimensionElectricity.ProductPricingStructure d_pps ON d_pps.ProductPricingStructureDurableKey = f.PriceStructureKey
        LEFT JOIN Dimensional_DW.DimensionElectricity.TouBanding d_tou ON d_tou.TouBandingDurableKey = f.PriceRateKey
        LEFT JOIN Dimensional_DW.DimensionElectricity.MeterPoint d_mp ON d_mp.MeterPointDurableKey = cmp.MeterPointKey
        LEFT JOIN Dimensional_DW.DimensionElectricity.PriceComponentAggregationType d_pcat ON d_pcat.[TnuosAggregationType] =pbat.[TNUoSAggType] AND d_pcat.[DuosAggregationType] =pbat.[DUoSFixedAvailAggType] AND d_pcat.[DuosUrcAggregationType] =pbat.[DUoSURCAggType] AND d_pcat.[BsuosAggregationType] =pbat.[BSUoSAggType] AND d_pcat.[ROAggregationType] =pbat.[ROAggType]
        LEFT JOIN Dimensional_DW.Dimension.Date AS d ON d.DateKey = CAST(CONVERT(NVARCHAR(8), f.DeliveryDate, 112) AS INT) 
        LEFT JOIN Dimensional_DW.Dimension.Date AS d_cw ON d_cw.DateKey = CAST(CONVERT(NVARCHAR(8), c.QuoteWonDate, 112) AS INT) 
        LEFT JOIN Dimensional_DW.DimensionElectricity.PowerPeriodCategory d_ppc ON d_ppc.HhPeriod = f.Period
        LEFT JOIN Dimensional_DW.Dimension.Customer d_cu ON d_cu.CustomerDurableKey = cu.CustomerKey
        LEFT JOIN Dimensional_DW.DimensionElectricity.ContractDetails d_cd ON d_cd.ContractDetailsDurableKey = c.ContractKey

WHERE  1=1
   and     c.ContractReference = @QuoteRef
   and c.QuoteWonDate IS NOT NULL 
   and c.QuoteKey <> -1
           --(SELECT distinct C.ContractKey FROM Electricity.Contract WHERE ContractReference = @QuoteRef and c.QuoteWonDate IS NOT NULL and c.QuoteKey <> -1)
                --(SELECT distinct C1.ContractKey FROM Electricity.Contract c1 WHERE c1.ContractReference = @QuoteRef and c1.QuoteWonDate IS NOT NULL and c1.QuoteKey <> -1)
        and mp.MpanID = @MpanRef
              --and c.ContractKey = 18235
              --and d.DateKey =  20180522
              order by [ForecastDateKey]

私の問題は、スカラー演算子であるnodeId 26の周りです：

enter image description here

5の行推定値がどのように生成されるのか私にはわかりません-これは、プランを他のほとんどの演算子にカスケードダウンするようです-ネストされたループオペレーターの推定実行カウントは、プランのさらに下にあり、すべて〜5の推定値を示し、その後〜実際の35k。

スカラー演算子に推定14,000行の推定値が与えられ、出力が5と推定されるのはなぜですか？これは問題ですか、それともレッドニシンですか？それが実行している変換と何か関係がありますか？結合に影響することは理解できますが、変換の出力に影響するのはなぜですか？

sql-serversql-server-2014optimizationexecution-plancardinality-estimates
4
George.Palacios

スカラー演算子に推定14,000行のフィードが与えられ、出力が5と推定されるのはなぜですか？これは問題ですか、それともレッドニシンですか？

これは直感に反しますが、クエリオプティマイザがプランスペースを探索する方法の自然な結果です。特定の計画演算子またはサブツリーに対して、論理的に同等の新しい代替案が生成されるため、新しいカーディナリティの推定値を導出する必要がある場合があります。

推定は統計的プロセスであるため、論理的に等価な（ただし物理的に異なる）ツリーから得られた推定が同じ数を生成するという保証はありません。実際、ほとんどの場合、生成されません。通常、ある見積もりを他の見積もりよりも優先する明白な方法はありません。

最適化が最終点に達すると、見つかった最良の代替案が「まとめられ」、最終的な計画が形成されます。この計画は結果として「不整合」をもたらす可能性があります。これは、推定値が異なる時点で異なる論理構造で計算されたためです。たとえば、Compute Scalarは、後で簡略化された論理集約として開始された可能性があります。

このことについては、私の記事 Indexed Views and Statistics で詳しく説明しました。

カーディナリティの誤った推定がプランの選択に（重要な方法で）影響していると思われる場合は、クエリを手動で分割するか、ヒントを使用するかを選択できます。ノード27またはその周辺の小さな中間セットを一時テーブルに具体化すると、オプティマイザがその時点で正確なカーディナリティを確認して自動統計を作成できるため、プランの品質が向上する可能性があります。クエリライターは、一時テーブルにインデックスを追加することもできます。

それが実行している変換と何か関係がありますか？結合に影響することは理解できますが、変換の出力に影響するのはなぜですか？

通常はありませんが、可能な限り変換を回避することが最善です。確かに変換はカーディナリティの推定に影響を与える可能性がありますが、それが原因である可能性はほとんどありません。

7
Paul White 9