記事ディレクトリ
インデックスの概要。
インデックスは、検索を高速化できるデータベース構造であり、テーブルまたはビューの1つ以上の列から生成されたキー、および指定されたデータストレージの場所にマップされたポインターが含まれます。適切に設計されたインデックスを作成すると、データベースクエリとアプリケーションのパフォーマンスを大幅に向上させることができます。たとえば、すべてのデータを保持するデータベースを1つの本と考える場合、インデックスはこの本のカタログです。インデックスを使用すると、検索速度が向上するだけでなく、テーブル内の行の一意性を強制できるため、データの整合性を確保できます。
インデックスが作成されると、DBMSによって自動的に管理および保守されます。ユーザーがレコードを挿入、削除、および変更すると、DBMSはテーブル内のインデックスを自動的に更新します。SQLクエリコードを記述する場合、インデックス付きのテーブルとインデックスなしのテーブルは同じ方法で使用されます。インデックスはある程度パフォーマンスを向上させることができますが、テーブルに多数のインデックスを作成しないようにする必要があります。そうしないと、データレコードの挿入、削除、変更のパフォーマンスに影響し、DBMSによるインデックス調整のオーバーヘッドが増加し、システム全体の応答が遅くなります。速度。
インデックスタイプ。
SQL Serverには、2種類の基本的なインデックスがあります。
- クラスター化インデックス
- 非クラスター化インデックス
さらに、次のインデックスがあります。
- 一意のインデックス
- インデックスを表示
- 全文索引
- XMLインデックス
クラスター化インデックス。
クラスター化インデックスのインデックスキーの論理的な順序は、データテーブルの実際の物理ストレージの順序と同じです。また、実際の物理ストレージのコピーは1つしかないため、データテーブルにはクラスター化インデックスを1つだけ含めることができます。クラスター化インデックスの作成と変更には非常に時間がかかるため、インデックスキーの論理的な順序に従って実際の物理ストレージの順序を再調整する必要があります。
SQL PRIMARY KEYで制約を作成するときに、データテーブルにクラスター化インデックスがなく、この制約に関係する列に一意の非クラスター化インデックスが適用されていない場合、システムはPRIMARY KEY関係する列に対して一意のクラスター化インデックスを自動的に作成します。作成するときにUNIQUE制約を、独自の非クラスタ化インデックスは、デフォルトで作成されます。データテーブルにクラスタ化インデックスが存在しない場合は、あなたが関与属性列のためにクラスタ化インデックスを指定することができます。
次の状況では、クラスター化インデックスの使用を検討できます。
- 100個の一意のステータスコードのみを含む列など、限られた数の一意の値を含む列。
BETWEEN>、<、> =、<=などの演算子を使用して、値の範囲のクエリを返します。- 大規模な結果セットを返すクエリ。
非クラスター化インデックス。
非クラスター化インデックスとクラスター化インデックスのインデックス構造は似ていますが、非クラスター化インデックスはデータ行の物理的な格納順序に影響せず、データ行の実際の物理的な格納順序はインデックスキーの論理的な順序と一致しません。また、各データテーブルには、クラスター化インデックスのような1つだけではなく、複数の非クラスター化インデックスを含めることができます。
クラスタ化インデックスと同様に、非クラスタ化インデックスもデータのクエリ速度を向上できますが、DBMSは非クラスタ化インデックスを含むデータテーブルのデータを更新する必要があるため、非クラスタ化インデックスが多すぎると、データの挿入と更新の速度が低下します。インデックス。テーブルでデータを頻繁に更新する必要がある場合は、非クラスター化インデックスをあまり作成しないでください。
一意のインデックス。
一意のインデックスを使用すると、インデックスキーに重複する値が含まれないようにすることができるため、テーブルの各行が何らかの方法で一意になります。[一意性]がデータ自体の特性である場合にのみ、一意のインデックスを指定することに意味があります。たとえば、studentテーブルの「ID番号」列の値を一意にしたい場合、studentテーブルのメインコードは「student number」ですが、「ID番号」にUNIQUE制約を作成できます。その後、この列に同じID番号を複数入力しようとすると、エラーメッセージが表示されます。複数列の一意のインデックスを使用すると、インデックスキー内の複数の列の組み合わせを一意にすることができます。
クラスタ化インデックスと非クラスタ化インデックスはどちらも一意にすることができます。つまり、一意のクラスタ化インデックスと一意の非クラスタ化インデックスを作成できます。ここでの一意性とは、インデックスの一意性ではなく、データの一意性を指すことに注意してください。前述のように、クラスター化インデックスにはデータテーブルを1つだけ含めることができますが、非クラスター化インデックスにはそのような制限はありません。
作成PRIMARY KEYおよびUNIQUE制約を設定すると、指定された列に対して一意のインデックスが自動的に作成されます。一意のインデックスを手動で作成し、その目的がデータの整合性を確保することである場合は、同時にUNIQUE制約またはPRIMARY KEY制約（実際にメインコードである場合）を作成することが列に最適です。
インデックスを表示します。
クエリビューによって返される結果セットは、クエリ基本テーブルによって返される結果セットと同じです。実際、標準ビューがクエリされると、SQL Serverは内部的にビューを解決し、それを基本テーブルのクエリに変換します。標準ビューの場合、その定義のみがDDに保持されます。ユーザーがビューを操作するたびに、定義に従って基本テーブルからデータが取得されます。このようにすると、動的に生成された結果セットをクエリするオーバーヘッドが特に高くなります。それらの複雑なビューのために。このようなビューに対するクエリ要件が多数ある場合は、これらのビューに一意のクラスター化インデックスを作成して、ビューインデックスと呼ばれるクエリのパフォーマンスを向上させ、インデックス付きのビューをインデックス付きビューと呼びます。一意のクラスター化インデックスがビューに作成された後、結果セットは、一意のクラスター化インデックスを持つ基本的なテーブルと同じようにデータベースに直接格納され、ビューのクエリパフォーマンスを効果的に向上させます。
前のインデックスと同様に、テーブル内のデータがほとんど更新されず、クエリ操作が多数ある場合、インデックス付きビューを使用すると効果が高くなります。逆に、インデックスを維持するためのコストは、インデックス付きビューを使用するメリットを相殺するか、それを超えます。
フルテキストインデックス。
フルテキストインデックスは、現在の検索エンジンの主要なテクノロジの1つです。1Mファイルで単語を検索する場合を想像してください。数秒かかることもあれば、100Mファイルの場合は数十秒かかることもあります。このタイプの検索を高速化するために、反転文書とも呼ばれるフルテキストインデックス技術が登場しました。原則は、最初にシソーラスを定義してから、記事内の各用語の頻度と位置を見つけて保存します。これは、シソーラスをディレクトリとして持つファイルのインデックスを確立することと同じであり、各単語をすばやく検索できます。単語の位置をターゲットにします。
インデックスを作成します。
SQLには、CREATE INDEXインデックスを作成するためのステートメントが用意されています。最初に、インデックスを作成するいくつかの例を示し、構文形式について説明します。
[例]テーブルSCのSNo列とCNo列に一意のインデックスを作成します。
CREATE UNIQUE INDEX SC_Index
ON SC(SNo,CNo)
上記のコードを実行した後、SC_Indexという名前の一意のインデックスがテーブルSCに対して作成されます。これは、SNoとCNoの2つの列の複合インデックスです。つまり、SCテーブルの行はSNoの昇順でソートされ、同じSNoはCNoの昇順でソートされます（デフォルトはASC増分です）。そのためのUNIQUESNO + CNOの組み合わせがユニークになるような制限、繰り返しません。
[例]教師テーブルTのTNにクラスター化インデックスを作成します。
CREATE CLUSTERED INDEX T_Index
ON T(TN)
インデックス作成の構文形式は次のとおりです。
CREATE [UNIQUE] [CLUSTERED|NONCLUSTERED] INDEX NAME_OF_INDEX
ON NAME_OF_TABLE|NAME_OF_VIEW(Col_1 ASC|DESC,Col_2 ASC|DESC,...)
それらの中でUNIQUE、ユニークな、CLUSTEREDそしてNONCLUSTERED集約と非集約を意味します。
インデックスを変更します。
インデックスを変更するコマンドはALTER INDEXです。
インデックスを削除します。
インデックスを削除する構文形式は次のとおりです。2つの形式があります。
DROP INDEX NAME_OF_TABLE|NAME_OF_VIEW.NAME_OF_INDEX
DROP INDEX NAME_OF_INDEX ON NAME_OF_TABLE|NAME_OF_VIEW