フィルタリングされた列を操作するのはなぜインデックス効率に影響しますか？

Question

私はBen Itzikの "Tsql Fundamental"を読んでいます。

インデックスを効率的に使用するには、フィルタリングされた列を操作しないでください。しかし、なぜこれが当てはまるのかについては詳細には触れていませんでした。

誰かがその理由を親切に説明できますか？

Answer 1

著者は、簡単に私たちは効率的

SARGABILITYと呼ばれる言及何著者インデックスを使用したい場合は、我々はフィルタ列を操作するべきではないと述べました。

select * from t1 where name='abc' 

を想定し、この文を想定し、あなたが上記のフィルタ列

にインデックスを持って、その後、クエリが

しかし、検索引数可能ではない1

select * from t1 where len(name)=3 

すると、以下のSQLは、上記のクエリで提示され、唯一の方法は、それはデータをフィルタにすることができますテーブルをスキャンして、各行に述語を適用してください。

Answer 2

インデックスを電話帳のように考えてみてください。

このインデックスは、あなたの電話番号を特定し、その姓（およびその住所）を知りたい場合に便利です。

しかし、（盗むためにTheGameiswar's exampleに）3文字の姓を持つ全員を検索する場合はどうすればよいですか？それは町のすべての家を訪れて訪問するよりも少し便利かもしれませんが、ですが、それはちょうど適切な姓にジャンプできるほど効率的ではありません。あなたは本全体を検索しなければなりません。

同様に、特定の通りに住んでいる人を探す場合は、インデックスはそれほど有用ではありません - 全員を見つけたことを確認するために書籍全体を検索する必要があります。それともこれは、データベースでの、インデックスが小さいという理由だけで、クエリを満たすためにインデックス・スキャンを実行することを選択できたときのためのアナロジーである

---

など、その姓Sonでを終了皆を見つけますし、フル・テーブル・スキャンよりも簡単です。

これは、インデックスの一番左の列をフィルタリングしようとしていないクエリの類推です。

Answer 3

SQLクエリのWHERE節は、述語を使用して行をフィルタリングします。述語は、データベースオブジェクトに適用された引数が真か偽かを判断する式です。例：「Salary> 5000」。

リレーショナル・モデルでは、述語をデータのフィルタリングの中核要素として使用します。これらの述部は、クエリー・オプティマイザーがデータをフィルター処理するためにWHERE節で使用されている属性に対して効果的に索引を使用するためには、「検索引数」という特定の形式で記述する必要があります。 "カラム - 演算子 - 値"または "値 - 演算子 - カラム"という形式の述語は、適切な検索引数とみなされます。例 - Salary = 1000またはSalary> 5000です。ご覧のとおり、列名は式の片側にALONEと表示され、有効な検索引数を構成するには定数または計算値が反対側にある必要があります。列名にMAX、MIN、DATEADD、DATEDIFFなどの組み込み関数が使用された時点で、式は検索引数として扱われなくなり、クエリオプティマイザはこれらの列名のインデックスを使用しません。

これは明らかです。