クラスター化インデックスと非クラスター化インデックスの説明

• 2019年2月11日
• 読むのに4分
• • M
  • M
  • C
  • M
  • r
  • +9

適用対象： SQL Server（サポートされているすべてのバージョン） AzureSQLデータベース

インデックスは、テーブルまたはビューに関連付けられたディスク上の構造であり、テーブルまたはビューからの行の取得を高速化します。インデックスには、テーブルまたはビューの1つ以上の列から作成されたキーが含まれます。これらのキーは、SQL Serverがキー値に関連付けられた1つまたは複数の行を迅速かつ効率的に検索できるようにする構造（Bツリー）に格納されます。

テーブルまたはビューには、次のタイプのインデックスを含めることができます。

• クラスター化

  • クラスター化インデックスは、キー値に基づいてデータ行をテーブルまたはビューに並べ替えて格納します。これらは、インデックス定義に含まれる列です。データ行自体は1つの順序でしか格納できないため、テーブルごとに1つのクラスター化インデックスしか存在できません。
  • テーブルのデータ行が並べ替えられた順序で格納されるのは、テーブルにクラスター化インデックスが含まれている場合のみです。テーブルにクラスター化インデックスがある場合、そのテーブルはクラスター化テーブルと呼ばれます。テーブルにクラスター化インデックスがない場合、そのデータ行はヒープと呼ばれる順序付けられていない構造に格納されます。

• 非クラスター化

  • 非クラスター化インデックスは、データ行とは別の構造になっています。非クラスター化インデックスには非クラスター化インデックスのキー値が含まれ、各キー値エントリには、キー値を含むデータ行へのポインターがあります。

  • 非クラスター化のインデックス行からのポインターデータ行へのインデックスは、行ロケーターと呼ばれます。行ロケーターの構造は、データページがヒープに格納されているかクラスター化されたテーブルに格納されているかによって異なります。ヒープの場合、行ロケーターは行へのポインターです。クラスター化テーブルの場合、行ロケーターはクラスター化インデックスキーです。

  • 非クラスター化インデックスのリーフレベルに非キー列を追加して、既存のインデックスキー制限をバイパスできます。完全にカバーされ、インデックスが付けられたクエリを実行します。詳細については、「含まれる列を使用してインデックスを作成する」を参照してください。インデックスキーの制限の詳細については、SQLServerの最大容量の仕様を参照してください。

クラスター化インデックスと非クラスター化インデックスの両方を一意にすることができます。これは、2つの行がインデックスキーに同じ値を持つことができないことを意味します。それ以外の場合、インデックスは一意ではなく、複数の行が同じキー値を共有できます。詳細については、「一意のインデックスの作成」を参照してください。

テーブルデータが変更されるたびに、テーブルまたはビューのインデックスが自動的に維持されます。

その他の種類の特殊目的インデックスについては、インデックスを参照してください。

インデックスと制約

PRIMARY KEYとUNIQUE制約がテーブル列に定義されると、インデックスが自動的に作成されます。たとえば、UNIQUE制約を使用してテーブルを作成すると、データベースエンジンは非クラスター化インデックスを自動的に作成します。 PRIMARY KEYを構成すると、クラスター化インデックスが既に存在しない限り、データベースエンジンはクラスター化インデックスを自動的に作成します。既存のテーブルにPRIMARYKEY制約を適用しようとし、クラスター化インデックスがそのテーブルにすでに存在する場合、SQLServerは非クラスター化インデックスを使用して主キーを適用します。

詳細については、「主キーの作成」および「一意の制約を作成します。

クエリオプティマイザによるインデックスの使用方法

適切に設計されたインデックスを使用すると、ディスクI / O操作が削減され、システムリソースの消費が少なくなるため、クエリのパフォーマンスが向上します。インデックスは、SELECT、UPDATE、DELETE、またはMERGEステートメントを含むさまざまなクエリに役立ちます。 AdventureWorks2012データベースのクエリSELECT Title, HireDate FROM HumanResources.Employee WHERE EmployeeID = 250について考えてみます。このクエリが実行されると、クエリオプティマイザは、データを取得するために使用可能な各メソッドを評価し、最も効率的なメソッドを選択します。この方法は、テーブルスキャンの場合もあれば、1つ以上のインデックスが存在する場合はスキャンする場合もあります。

テーブルスキャンを実行すると、クエリオプティマイザはテーブル内のすべての行を読み取り、一致する行を抽出します。クエリの基準。テーブルスキャンは多くのディスクI / O操作を生成し、リソースを大量に消費する可能性があります。ただし、たとえば、クエリの結果セットがテーブルの行の割合が高い場合は、テーブルスキャンが最も効率的な方法です。

クエリオプティマイザがインデックスを使用する場合、キー列にインデックスを付け、クエリに必要な行の格納場所を見つけ、その場所から一致する行を抽出します。一般に、インデックスの検索はテーブルの検索よりもはるかに高速です。これは、テーブルとは異なり、インデックスに含まれる列が行ごとに非常に少なく、行が並べ替えられているためです。

クエリオプティマイザは通常、クエリを実行するときに最も効率的な方法を選択します。 ただし、使用可能なインデックスがない場合、クエリオプティマイザはテーブルスキャンを使用する必要があります。 あなたの仕事は、クエリオプティマイザが選択できる効率的なインデックスを選択できるように、環境に最適なインデックスを設計および作成することです。 SQL Serverは、データベース環境の分析と適切なインデックスの選択に役立つDatabase Engine TuningAdvisorを提供します。

• SQLServerインデックスデザインガイド
• クラスター化インデックスの作成
• 非クラスター化の作成 インデックス