SSMSプランからの不適切なカーディナリティ推定

3年以上前に、SQL Server2008以降でフィルター述語を使用したキー/RIDルックアップの場合に、SQLServerのShowplanXMLが生成していたカーディナリティの推定値の誤りに関するPlanExplorerの修正について投稿しました。 Management Studioの表示に関係なく、これらの計画の1つと、正しいメトリックを表示していることを確認するために行った反復について、振り返ってもう少し詳しく調べるのは興味深いと思いました。繰り返しになりますが、この作業は主にBrooke Philpott（@MacroMullet）とGreg Gonzalez（@SQLsensei）によって行われ、Paul White（@SQL_Kiwi）からのすばらしい意見が寄せられました。

これは、以前の投稿で提示したPaulからのクエリと非常によく似ています（少なくともトランザクションの日付が変更された最新バージョンのAdventureWorksで正確に再現するには、ある程度の作業が必要です）：

SELECT
    th.ProductID,
    p.Name,
    th.TransactionID,
    th.TransactionDate
FROM Production.Product AS p
JOIN Production.TransactionHistory AS th ON
    th.ProductID = p.ProductID
WHERE 
    p.ProductID IN (1, 2)
    AND th.TransactionDate BETWEEN '20070901' AND '20071231';

Management Studioの計画は十分に正しいように見えました：

ただし、よく見ると、ShowPlanは、キールックアップからの推定実行数を、最終的な交換の推定行数に直接プッシュしたようです。

一見すると、Plan Explorerのグラフィカルな計画図は、SSMSが作成する計画と非常によく似ています。

さて、Plan Explorerを開発する過程で、ShowPlanがその計算を完全に正しく行わないいくつかのケースを発見しました。最も明白な例は、合計が100％を超えるパーセンテージです。これは、SSMSが途方もなくオフになっている場合に正しく行われます（今日、これは以前よりも頻繁に見られませんが、それでも発生します）。

もう1つのケースは、SQL Server 2008以降、SSMSがルックアップとともに実行ごとの行ではなく、推定行の合計を配置し始めた場合ですが、述語がルックアップにプッシュされた場合のみです（Paulによって報告されたこのバグの場合など）。そして、Joey D'Antoniによるこの最近の観察）。以前のバージョンのSQLServer（および関数とスプールを使用）では、通常、実行ごとの推定行数（通常は1）にSSMSによる推定行数を掛けることにより、ルックアップから得られる推定行数を表示していました。しかし、この変更により、オペレーターはすでにその計算を行っているため、過大評価されることになります。したがって、以前のバージョンのPlan Explorerでは、2008以降では、ツールチップ、コネクタライン、またはさまざまなグリッドにこれらの詳細が表示されます。

（1,721はどこから来たのですか？67.5の推定実行x 25.4927の推定行。）

2012年に、この数学演算を実行せず、キールックアップから得られる推定行数のみに依存することで、この問題の一部を修正しました。これはほぼ正しかったのですが、ShowPlanが最終的な交換のために提供してくれた推定行数に依然頼っていました：

バージョン7.2.42.0（Hallowe'en 2012でリリース）でもこの問題にすばやく対処し、Management Studioよりもはるかに正確な情報を提供していると感じています（ただし、Paulからのこのバグに注目します）。：

これは明らかに昔のことですが、それでも共有するのは面白いと思いました。可能な限り最も正確な情報を提供するために、Plan Explorerの機能強化を継続しており、今後の投稿でこれらのナゲットのいくつかを共有します。

SSMSプランからの不適切なカーディナリティ推定– redux