SQLServerでのデータベースインデックス設計に関する5つの考慮事項

データベースインデックスは、さまざまなテーブル操作を高速化するために使用されます。ただし、インデックスを作成する前に、本当にインデックスが必要かどうかを知ることが重要ですか？また、インデックスを作成する必要がある場合、留意しなければならない重要なポイントは何ですか？これがデータベースインデックスの設計の出番です。

この記事は、データベースインデックスの設計に関するこれらの質問に答え、データベース開発者がインデックスを設計するときに考慮すべき主要な考慮事項のいくつかに光を当てることを目的としています。

1。テーブルサイズ

データベース開発者がインデックスを作成する前に尋ねなければならない最初の質問は、テーブルがインデックスを効率的に使用するのに十分な大きさであるかどうかです。テーブルサイズが小さい場合、SQL Serverエンジンは、インデックスを介してテーブルを検索するよりも迅速にテーブル全体をスキャンできます。このような場合のインデックスは役に立たず、データベース操作の実行中にオーバーヘッドが発生します。

2。列タイプ

インデックスは、主キー列、または一意の値を含み、NOTNULL制約がある任意の列に作成する必要があります。さらに、数値列は非数値列に比べて一意の値を持つ傾向があるため、数値列にインデックスを作成することをお勧めします。不十分なデータベースインデックスの設計では、一意のエントリが非常に少ない列でインデックスを使用するため、クエリに非常に時間がかかる可能性があります。

数十万のレコードを含むPatientsという名前のテーブルについて考えてみます。 Patientsテーブルには、「Gender」という列が含まれます。この列には、「Male」と「Female」の2つの一意の値しかありません。 「性別列」にインデックスを作成すると、レコードはアルファベットの昇順または降順で並べ替えられます。

したがって、Patientsテーブルに100万件のレコードがあり、男性と女性の患者数が等しい場合、インデックスでは、最初の50万件のレコードの性別は「女性」、後半の50万件のレコードの性別は「男性」になります。ここで、女性レコードの490,000行目に存在する女性を検索する場合、SQLServerエンジンは490,000レコードをスキャンする必要があります。一方、一意の数値を使用すると、SQLServerインデックスがB+ツリーの形式で格納されるため、検索が非常に高速になり、ツリーノードの数値によってデータベース操作が高速化されます。

3。インデックスの数

公式には、データベーステーブルごとに1つのクラスター化インデックスと必要な数の非クラスター化インデックスを作成できます。ただし、1つのクラスター化インデックスと、絶対に必要な限られた数の非クラスター化インデックスのみを作成することは、優れたデータベースインデックス設計です。非クラスター化インデックスを作成しすぎると、実際には更新および挿入操作が遅くなる可能性があります。これは、レコードが更新または挿入され、列の値が変更された場合、関連するすべてのインデックスを更新する必要があるためです。

2つの非クラスター化インデックスがあり、最初のインデックスがレコードを年齢で並べ替え、2番目のインデックスが性別と年齢の両方でレコードを並べ替えるシナリオを考えてみます。

これが最初のインデックスです：

そしてここに2番目があります：

ここで、何らかの理由で40歳のレコードを15歳に更新する必要がある場合は、インデックスを並べ替えたままにするために、最初のインデックスを更新して、レコードを7番目の位置（40）から2番目の位置に移動する必要があります。同様に、2番目のインデックスでは、4番目のインデックスのレコードが2番目のインデックスに移動されます。多くの改造が行われなければなりません。したがって、データベースインデックスの設計を検討するときは、定期的に更新される列のインデックスの数を最小限に抑えることをお勧めします。また、1つの列を複数の非クラスター化インデックスで使用しないでください。

4。インデックスの保存場所

インデックスの格納場所は、インデックスを使用するクエリのパフォーマンスに影響を与える可能性があるため、優れたデータベースインデックス設計の一部でもあります。デフォルトでは、クラスター化されたインデックスは、インデックスが作成されたテーブルと同じファイルグループに格納されます。非クラスター化インデックスの場合、インデックスは同じファイルグループに保存することも、複数のディスクドライブにまたがる異なるファイルグループに保存することもできます。非クラスター化インデックスのクエリパフォーマンスは、非クラスター化インデックスを複数のディスクドライブに格納することで大幅に向上させることができます。これは、データがドライブのさまざまな領域に分散される結果として、クエリの入出力パフォーマンスが向上するためです。

FILLFACTORオプションの値を指定することにより、索引のデフォルトの保管場所を変更することもできます。インデックスは物理的にB+ツリーの形式で保存されるため、インデックスデータはリーフページに保存されます。 FILLFACTORオプションを使用すると、塗りつぶされるリーフレベルのページのパーセンテージを設定できます。たとえば、FILLFACTORの値を70％に設定すると、リーフレベルのページの合計スペースの70％のみがインデックスデータで埋められます。残りの30％は、将来的にインデックスデータの自動拡張のために残されます。

5。インデックスタイプ

データベースインデックスの設計におけるもう1つの非常に重要な考慮事項は、使用するインデックスのタイプです。以前の記事（「クラスター化インデックスまたは非クラスター化インデックスを使用する場合」の記事へのリンクを追加）で、クラスター化インデックスと非クラスター化インデックスの違いについて説明しました。また、それらが何であるか、そしてそれらがどのように使用できるかについても説明しました。クラスター化されたインデックスとクラスター化されていないインデックスのどちらを選択するかを決定することは非常に重要であり、慎重に検討する必要があります。

選択するインデックスタイプを決定する際には、次の点に注意する必要があります。

1. SELECT / JOIN / GROUP BY / BETWEENクエリで使用される列には、クラスター化インデックスを使用します。
2. 同じ行の他の列からではなく、その特定の列からのみ値を取得する列には、非クラスター化インデックスを使用します。非クラスター化インデックスを使用して複数のレコードを取得するSELECTクエリは、SQL Serverエンジンが最初にインデックスが作成された列値を検索し、次に列値の行参照を使用して実際のデータベーステーブルからレコードを取得するため、処理が遅くなる可能性があります。 。
3. INSERTおよびUPDATE操作が頻繁に行われる列には、非クラスター化インデックスを使用します。複数の非クラスター化インデックスで1つの列を使用しないようにしてください。これにより、更新クエリの速度が低下する可能性があります。非クラスター化インデックスの場合のように単一の列値だけではなく、行全体を更新する必要があるため、クラスター化インデックスはINSERT/UPDATE操作で遅くなる可能性があります。
4. 作成できるクラスター化インデックスは1つだけなので、複数のインデックスが必要な場合は、非クラスター化インデックスを使用します。ただし、ディスクスペースが主な懸念事項である場合は、非クラスター化インデックスの数を最小限に抑えてください。

その他の考慮事項

これらはデータベースインデックス設計の5つの最も重要な部分ですが、すべてではありません。インデックスの列の正しい順序を指定することが重要です。経験則として、WHERE句の意思決定に使用される列、およびより大きい（>）、より小さい（<）などの条件は、これらの句に含まれない列の前に配置する必要があります。 WHERE句に複数の列がある場合は、最も特徴的な列名をインデックス定義の最初に記載する必要があります。

データベースインデックスの設計とは別に、クエリの設計もインデックスの設計を効率的に使用する上で重要な役割を果たします。少数の行を操作する複数のクエリを作成する代わりに、インデックスのメンテナンスを最適化するには、多数のテーブル行に影響を与えるクエリを少なくしてください。

結論

この記事では、データベース開発者がデータベースインデックスの設計を検討する際に考慮しなければならない主な考慮事項のいくつかについて説明します。この記事では、これらの考慮事項の背後にある理論的根拠についても説明し、データベースインデックスの設計が効率的であることを確認するためのさらなる提案が含まれています。