SQLのインデックスとは何かを考えてみてください。インデックスは、実際には他のメモリのチャンク（つまり、行へのポインタ）を指すメモリのチャンクです。インデックスはページに分割されているため、使用状況に応じてインデックスの一部をメモリにロードしたり、メモリからアンロードしたりできます。
行のセットを要求すると、SQLはインデックスを使用して、テーブルスキャン（すべての行を調べる）よりも迅速に行を検索します。
SQLには、クラスター化インデックスと非クラスター化インデックスがあります。クラスタ化インデックスについての私の理解は、それらが類似のインデックス値を同じページにグループ化することです。このように、インデックス値に一致するすべての行を要求すると、SQLはメモリのクラスター化されたページからそれらの行を返すことができます。これが、GUID列のクラスターインデックスを作成することはお勧めできない理由です。ランダムな値をクラスター化しようとはしません。
整数列にインデックスを付けると、SQLのインデックスには各インデックス値の行のセットが含まれます。 1から10の範囲がある場合、10個のインデックスポインタがあります。行数に応じて、ページを変えることができます。クエリが「1」に一致するインデックスを検索し、Nameに「Fred」が含まれている場合（Name列にインデックスが付けられていない場合）、SQLは「1」に一致する行のセットをすばやく取得し、テーブルスキャンで残りを検索します。
つまり、SQLが実際に行っているのは、反復処理する必要のあるワーキングセット（行数）を削減しようとしているということです。
ビットフィールド（またはいくつかの狭い範囲）にインデックスを付ける場合、その値に一致する行の数だけワーキングセットを減らします。一致する行の数が少ない場合は、ワーキングセットが大幅に減少します。 50/50の分布を持つ多数の行の場合、インデックスを最新の状態に保つのに比べて、パフォーマンスの向上はほとんど得られない可能性があります。
誰もがテストすると言う理由は、SQLには非常に巧妙で複雑なオプティマイザーが含まれているためです。このオプティマイザーは、テーブルスキャンが高速であると判断した場合、インデックスを無視する場合、並べ替えを使用する場合、またはメモリページを整理する場合があります。