以下のようにクラスタ化インデックスを持つサンプルテーブルを作成し、1500レコードを挿入しました。プライマリキーのある場所でClusteredIndexSeekを取得できません
CREATE CLUSTERED INDEX IX_mytable_myid ON dbo.MyTable(myid)
以下のクエリを実行すると、シークの代わりにクラスタ化インデックススキャンが実行されていることがわかりました。インデックステーブルがスキャンされる理由がわかりません。
SELECT myid FROM dbo.MyTable WHERE myid=1666
謝罪。私は実行計画の警告シンボルを通してそれを特定し、myidフィールドが実際にvarcharであり、暗黙的な変換が行われていることが判明しました。
からmyidを選択してください。myByMyTable myid = '1666' シークします。
それは私が期待していたものではありません。 myID列が実際にvarcharの場合は、静的な値（つまり1666）をvarcharに暗黙的に変換してからSQLで実行することを期待していました（同等のテーブル側で暗黙の変換を行うのではなく）。なぜあなたがスキャンを見ているのか疑問に思うのはあなたのテーブルが小さいことです。 1500行はほんの数ページであり、小さなテーブルの場合は、読み込みが必要なページ数を調べるよりもテーブル全体をスキャンするほうが効率的です。 –
@BenThul私はあなたのことを理解しています。しかし、myid = '1666'と照会するときに同じ数のレコードを探します。私が理解していることは、データ型が不一致であれば予測不可能なバイナリツリー検索でシークできることです。したがって、インデックススキャンが起こったでしょう。 –
私の理解が間違っている場合は、私を修正してください。話してくれてありがとう。 –
forceeekヒントを使用してSQL Serverにインデックスを検索させることができます – bmsqldev
ヒントを示すためにありがとうございます。問題が特定されました。 –