非クラスター化インデックスで作成された番地フィールドで非クラスター化インデックスプランを使用するクエリを作成しようとしています。私が抱えている問題は、番地を検索している場合、「like」eval関数を使用している可能性が高いということです。この関数を使用すると、インデックスを使用する代わりにテーブルスキャンが発生すると思います。この場合、どうすれば書くことができますか?非クラスター化インデックスをaddress3フィールドに配置するのは無意味ですか?前もって感謝します。
4 に答える
LIKE 式が文字列の開始検索 ( Address LIKE 'Blah%'
) を実行している場合、おそらくインデックス シークを通じてインデックスが使用されると予想されます。
を検索するAddress LIKE '%Blah%'
と、クエリで返されるフィールドの数とインデックスの選択性に応じて、テーブル スキャン/インデックス スキャンが実行されます。
varchar フィールドは、辞書や百科事典にインデックスが付けられるのとほぼ同じように、左から右にインデックスが付けられます。
フィールドの始まりがわかっている場合 (例: LIKE 'streetname%')、インデックスは効率的です。ただし、フィールドの一部しか知らない場合 (例: LIKE '%something%')、インデックスは使用できません。
LIKE を使用しても、必ずしもテーブル スキャンが使用されるわけではありません。検索対象の文字列に応じて、インデックスを使用する場合があります。(たとえば、LIKE 'something%' は一般的にインデックスを使用できますが、LIKE '%something' はおそらくそうではありませんが、その場合でもサーバーは少なくともインデックス スキャンを実行できる可能性があります。単純なインデックス ルックアップですが、完全なテーブル スキャンよりも安価です。) SQL Server に関して LIKE とインデックスについて説明している良い記事がここにあります (明らかに、異なる DBMS では異なる方法で実装されます)。
理論的には、データベースは最適なインデックスを使用します。どのデータベース サーバーを使用しているか、実際に何を達成しようとしているのか、LIKE ステートメントはどのようなものになるのでしょうか? たとえば、ワイルドカード文字がどこにあるかによって、使用されるクエリ プランが異なります。
達成したいことに応じて、データの前処理を実行し、検索に役立つ他の列を作成したり、インデックス付きビューを使用したりする可能性があります。
ここでは、SQL Server 2005 および varchar フィールドでのインデックスの使用について説明します。