SSMS実行計画からの不適切なカーディナリティ推定

SQL SentryPlanExplorerの最近の更新に感謝する人が何人かいます。 Brooke Philpott（@Macromullet）とGreg Gonzalez（blog | @SQLsensei）は、もちろん、研究開発とコードの掘り下げと分類に携わっています。しかし、修正の検証を支援してくれたPaul White（ブログ| @SQL_kiwi）にも感謝します。

Paulが発見した問題は、SQL Server 2008+が、キーまたはRIDのルックアップが含まれている場合に、特定のクエリのカーディナリティの見積もりを台無しにすることです。より深い説明はPaulのブログ投稿と彼がConnectに提出したバグに任せますが、簡単に言えば、私たちはこれらの誤って伝えられた見積もりを取り、それらを信じて、「より良い」情報を示すためにそれらを推定していました。残念ながら、ポールが説明しているように、私たちはだまされました。

Paulは、AdventureWorks2005のコピーに対して次のクエリを示しています。

SELECT
    th.ProductID,
    th.TransactionID,
    th.TransactionDate
FROM Production.TransactionHistory AS th 
WHERE 
    th.ProductID = 1 
    AND th.TransactionDate BETWEEN '20030901' AND '20031231';

Management Studioは、Paulが説明したように、次の計画を作成します。

Plan Explorerでは、推定行数（17に四捨五入）に実行数（45）を掛けて役立つようにし、765を作成しました。

ほとんどのオペレーターにとって、このアプローチは正しいデータを生成しますが、SQL Serverのこのバグのため、キー/RIDルックアップには正しくありません。そのために調整し、7.2.42.0で適切な修正をリリースしました（今すぐダウンロードしてください！）。グラフィカルな計画で、両方の推定値の正しい行数が正しく表示されるようになりました。

そして実際：

Paulの警告を繰り返します。ルックアップの一部として述語が適用される場合は、カーディナリティの推定値が低くなることに注意してください。

これらの誤解を招く見積もりによって引き起こされるいくつかのより複雑な問題がありましたが、これについても対処しました。フォローアップの投稿でそれらのいくつかについてブログを書きます–この投稿では、ポールが彼の投稿で強調した特定の問題を迅速に解決したことを示したかっただけです。