SQL Serverは、合計6,000％になるクエリ実行プランをどのように生成しますか？
今日私はThe Heapにいて、改善できると思ったもののクエリプランを見ていました。ただし、SQL Serverクエリオプティマイザーに対する私の信念を揺るがす何かを作成しました。 100％に数えることさえできない場合でも sql-server を信頼できますか？
テーブルの特徴：
- 非ID列でクラスター化
- 12個のインデックス、そのうちの1つは
date_entered問題の列 - 60,000レコード
- さまざまなタイプと長さの26列
- PAGE圧縮テーブル
誰かがこれを以前に見たことがありますか、そして計画がそれほど歪んでいるように見える原因は何ですか？
このバグは何年も前から知られており、修正されることはありません。最初に報告したのは6年前ですが、それよりずっと長く存在しています。これらは推定コストであり、オプティマイザ自体にはまったく影響せず、信頼できるかどうかも関係ありません。疑わしい計算が含まれているのは、単にshowplanの出力です。
解決策： SQL Sentry Plan Explorer *を使用します。ここでは、適切な計算が行われる傾向があります（または単に推定コストを見ることをやめ、より意味のあるメトリックを見ること）。このプランをプランエクスプローラーで開くと、パーセンテージが正しく加算されることを保証します。
免責事項：私はSQL Sentryで働いています。