次のようなクエリがあるとします。
select a.col1, b.col2
from t1 a
inner join t2 b on a.col1 = b.col2
where a.col1 = 'abc'
両方ともインデックスがcol1ありcol2ません。
where句に別の制限を追加すると、常に正しいが、インデックスのある列があります。
select a.col1, b.col2
from t1 a
inner join t2 b on a.col1 = b.col2
where a.col1 = 'abc'
and a.id >= 0 -- column always true and with index
id列のインデックスを使用する可能性があるため、クエリのパフォーマンスが向上しますか？
インデックスを使用idして何をしますか?
ここで最もコストがかかるのは、結合列の結合であり、それとidは何の関係もありません。
ほとんどの場合、違いはありません。
id考えられる結果:常にゼロより大きいとは限らないため、より多くの時間がかかります。そのため、インデックス スキャンを実行して正しい行を見つけ、そこからテーブルから取得したのと同じ行を取得します。 -scan (問題の列を覆うカバーがあった場合、おそらく異なるでしょうINCLUDE)。
とんでもない結果: データベースの最適化の世界ではもっと奇妙なことが起こったので、それが役に立ったなら私は帽子を食べませんが、それでも私は非常に驚くでしょう.
ただし、実際には、無関係なインデックスを使用して無関係な作業を強制しても、あなたの目的には役立ちません。
編集：実際、それが役立つケースを考えました。SQLServer は一般に、直接関連するインデックスがない場合でも、何らかのインデックスを使用してシークします。その場合でも、シークは一般にスキャンよりも優れているためです。何らかの理由でそのシークの方が優れていて、何らかの理由で別のインデックスをシークするように選択した場合、別のインデックスへのシークを強制することで、問題が改善される可能性があります。それでもかなり驚かれると思います。
実際はもっと悪いと思います。ここでインデックスを使用してすべての行を取得すると、単純にすべての行を取得する場合に比べて余分な作業が必要になるためです。
質問に対する答えは「はい」です。テーブル a の行を十分に除外すると、パフォーマンスが向上します。
おそらく（しかしありそうもない）。これはすべて、クエリ オプティマイザがクエリを評価する方法にかかっています。より良いオプションは、ヒントを使用することです。