SQL Serverのインデックスの疑問

Question

SQLクエリのパフォーマンスを向上させるためにインデックスが使用されていますが、インデックスを使用する必要があるかどうかを判断することはほとんど困難です。非クラスタ化インデックスに関する疑問を明確にしたい

1. クラスタ化されていないインデックスキーとは何ですか？本のように、非クラスタ化インデックスの各インデックス行には非クラスタ化されたキー値が含まれているので、クラスタ化されていないインデックスを作成した列です。つまり、empname varchar（50） 。

2. なぜ小さい幅の列にインデックスを作成するのが望ましいですか。これは、より幅の列との比較によると、SQL Serverエンジンの時間がかかるためです。ページサイズが固定されているため、中間ノードの階層が増えます。

3. テーブルに複数の非クラスター化された列が含まれている場合、非クラスター化されたキーがこの列のすべての組み合わせであるかどうか、または実際のデータ行を指すロケーターを使用して内部的にSQLによって生成されます。可能であれば、リアルタイムの例とグラフをクリアしてください。

4. なぜ反復可能な値を持つ列は、繰り返し値を含んでいてもインデックスを作成するのに適していると言われますが、特定のキー値に達すると確実にパフォーマンスが向上します。

5. 索引付けで使用される列が、表からの実際のデータ行の検索方法に固有でない場合。

疑問を解決するのに役立つ本またはチュートリアルを参照してください。

Answer 1

まず、実際のインデックスが何であるかを説明する必要があると思います。通常、RDBMSインデックスでは、B-tree'sのバリアントを使用して実装されています（B +バリアントが最も一般的です）。まもなく言えば、バイナリ検索ツリーはディスク上に保存されるように最適化されていると考えてください。通常、Bツリーのキーを検索した結果がテーブルの主キーです。つまり、インデックスのルックアップが完了し、インデックスに存在するものよりも多くのデータが必要な場合は、プライマリキーを使用してテーブル内でシークを実行できます。

RDBMSのパフォーマンスを考えるとき、私は通常、ディスクアクセス（これはロックやその他の問題はここで無視することにします）ではなく、あまりCPU時間ではないと判断します。

索引を非クラスタ化すると、表のデータが実際に格納される方法は索引キーとは関係ありませんが、クラスタ化索引では表のデータをソート（またはクラスタ化）インデックスキー - これは、テーブルごとに1つのクラスタ化インデックスのみが存在する理由です。

2）パフォーマンスの測定モデルに戻って、インデックスキーの幅が狭い（少ないバイト数に収まる）場合、取得するディスクデータのブロックごとに、より多くのキーを収めることができます。ディスクI/Oを測定する場合、Bツリーのルックアップをはるかに高速に実行します。

3）私はこれをさらに詳しく説明しようとしました。残念ながら、これを示すためのグラフや図は実際にはありません。

4）あなたがそうのようなクエリ実行している場合：そのように定義されたインデックスを持つテーブルの上に

SELECT something, something_else FROM sometable t1 WHERE akey = 'some value' 

を：

CREATE INDEX idx_sometable_akey ON sometable(akey) 

sometable行の多くを持っている場合AKEYが同じです'some value'には、インデックスと実際のテーブルのルックアップがたくさんあり、somethingとsomething_elseの値を取得します。一方、このフィルタリングで行が少なくなる可能性が高い場合は、ディスクへのアクセスも少なくなります。

5）このことができます:)