1つの大きな表と2つの小さな表が内部で結合されています。大きなテーブルに適切なインデックスを追加しました。クエリーが高速であっても（ほとんどの場合）、何回か、3秒以上かかることがあります。私は実行計画をチェックすると、キーの参照の代わりにインデックスの代わりに行くSQLのようだ。SQLはインデックス付き列をシークする代わりにキールックアップを行います
ここは私の質問です。
と私の実行計画。
、ここで実行の詳細;
私はここで何かが足りないのですか？
キー検索はシークです。キーを使用して検索しています。 （表は、あなたが「しおりのルックアップ」を得る。その場合には、クラスタ化されていない場合、代わりにまたはRID物理）前のインデックスに使用されるインデックスを求めるので
は、非クラスタ化インデックスは常に
クラスタ化インデックスキーを含みCreateDate列が含まれていない場合は、クラスタードインデックスキーを使用してクラスタードインデックスを検索して取得する必要があります。追加の列を検索するこのタイプのシークは、キー参照と呼ばれます。
ルックアップを削除したい場合は、NewsCategoryUrlIdのインデックスにCreateDateをinclude dという列として追加することを検討してください。
コメントで、あなたのケースはパラメータスニッフィングや古い統計のように聞こえますが。オプティマイザがパラメータ値が選択的であると判断し、選択的でない場合に問題となる場合は、非カバー索引シークおよびキー・ルックアップを含むプランが生成されることがあります。
パラメータスニッフィングを使用すると、計画が選択値用にコンパイルされ、キャッシュされて、それほど選択的でない値に再利用される場合に、問題が発生する可能性があります。
古くなった統計は、プランが最初にコンパイルされたパラメータ値の真の選択性を反映していない可能性があります。
ありがとう！ CreateDateとNewsCategoryUrlIdを含む索引を作成すると示唆されました。そして私はかなり正確なタイミングを得ています。あなたの提案を含めるように私の質問を更新しました。 –
マーティンスミスからの提案を受けて、私は以下のようにインデックスを作成し直しました。
、今、実行計画は、私にとっては満足ドロドロです。私は間違いなくあなたがパラメータスニッフィングを持っていることだ
は 'あなたは、クエリの実行時間がどのように影響を与えてしまいますあなたが使用した場合（'オプションを（ '）未知の最適化）@ newscategoryid' – Monah
を確認することができますか？ – Monah
解決策を質問から回答に移動することを検討してください（あなたは回答を作成できます）。私はそれをupvoteできるように私に知らせてください。 – 2501