1
SQL Server 2008の "OPTIMIZE FOR UNKNOWN"クエリプランオプションの理論とビューを読んだことがあります。私はそれが十分にうまくいくことを理解する。OPTIMIZE FOR UNKNOWNをいつ使用するかについての経験
私はいくつかの限られた実験を行い、暖かいキャッシュでは100kを超える行にしか効果がなかったことがわかりました。しかし、これはシンプルなテーブルであり、結合やフィルタリングなどのないクエリであった。コールドキャッシュでは、間違いなくその画像がはるかに有利になるだろう。
私は現在、前/後のベンチレーションのための生産システムを持っていません。だから、もし誰かがテストの前後に行って、このオプションをいつ使うべきか、そうでない時に、何か有益な発見をしたのなら、私は不思議です。
UPDATE：
I 3つのCOLS、UIDにPK、とcol2（INT）にインデックスを持つテーブルを作成しました。すべての処理はCol2に対して行われました。行と時間（DATEDIFF * 1000000）の数が示されます。
Type 1,000 5,000 20,000 100,000
Normal 0.3086 6.327 26.427 144.83, 141.126
Recompile 117.59 584.837
For Unknown 0.8101 6.52 26.89 143.788, 143.248
「@UID = 100000」では、シークではなくインデックススキャンを引き起こすプランが常に悪いと主張することができます。 MSDNのブログは、ベストプラクティスについて非常に漠然としていて、ここで言いたいことだけを与えています。残りの質問は状況を悪化させるシナリオを強調しているので、IMOは非常に関連性があります。 – IamIC
@IanC - 書かれているように完全に答えることはできません。行数は、実行計画のコンテキストなしでは何も意味しません。 –
私はそれを理解しています。私が求めているのは、いくつかのケーススタディだけです。これは、「ハイパースレッドがSQL Serverを傷つけたり、助けてくれる」質問によく似ています。 「はい/いいえ」の回答はありません。あらゆるタイプの答えを見つける唯一の方法は、いくつかのケーススタディを研究し、パターンを推測することです。これはこのシナリオで行われ、結論に達しました。私が求めていることに対してもそれは可能です。 – IamIC