クラスター化インデックスと非クラスター化インデックスの概念Clustered and Nonclustered Indexes Described

適用対象:Applies to: はいSQL ServerSQL Server (サポートされているすべてのバージョン) yesSQL ServerSQL Server (all supported versions) はいAzure SQL データベースAzure SQL DatabaseYesAzure SQL データベースAzure SQL Database適用対象:Applies to: はいSQL ServerSQL Server (サポートされているすべてのバージョン) yesSQL ServerSQL Server (all supported versions) はいAzure SQL データベースAzure SQL DatabaseYesAzure SQL データベースAzure SQL Database

インデックスとは、テーブルまたはビューに関連付けられたディスク上の構造で、テーブルやビューからの行の取得を高速化します。An index is an on-disk structure associated with a table or view that speeds retrieval of rows from the table or view. インデックスには、テーブル内またはビュー内の 1 つ以上の列から構築されたキーが含まれています。An index contains keys built from one or more columns in the table or view. これらのキーは 1 つの構造 (B-Tree) 内に格納され、 SQL ServerSQL Server はその構造を使用して、キー値に関連した 1 つ以上の行を効率よく迅速に検出できます。These keys are stored in a structure (B-tree) that enables SQL ServerSQL Server to find the row or rows associated with the key values quickly and efficiently.

テーブルまたはビューには、次の種類のインデックスを含めることができます。A table or view can contain the following types of indexes:

  • クラスター化インデックスClustered

    • クラスター化インデックスは、テーブルまたはビュー内のデータ行をそのキー値に基づいて並べ替え、格納します。Clustered indexes sort and store the data rows in the table or view based on their key values. クラスター化インデックスは、インデックス定義に含まれる列です。These are the columns included in the index definition. データ行自体は 1 つの順序でしか並べ替えられないので、1 つのテーブルに設定できるクラスター化インデックスは 1 つだけです。There can be only one clustered index per table, because the data rows themselves can be stored in only one order.
    • テーブル内のデータ行が並べ替えられた順に格納されるのは、テーブルにクラスター化インデックスが含まれているときだけです。The only time the data rows in a table are stored in sorted order is when the table contains a clustered index. テーブルにクラスター化インデックスが含まれている場合、そのテーブルをクラスター化テーブルと呼びます。When a table has a clustered index, the table is called a clustered table. クラスター化インデックスが含まれないテーブルのデータ行は、ヒープと呼ばれる順序付けられていない構造に格納されます。If a table has no clustered index, its data rows are stored in an unordered structure called a heap.
  • 非クラスター化インデックスNonclustered

    • 非クラスター化インデックスは、データ行とは独立した構造になっています。Nonclustered indexes have a structure separate from the data rows. 非クラスター化インデックスには、非クラスター化インデックスのキー値が含まれており、各キー値のエントリにはキー値が含まれているデータ行へのポインターが含まれています。A nonclustered index contains the nonclustered index key values and each key value entry has a pointer to the data row that contains the key value.

    • 非クラスター化インデックス内のインデックス行からデータ行を指すポインターを、行ロケーターと呼びます。The pointer from an index row in a nonclustered index to a data row is called a row locator. 行ロケーターの構造は、データ ページがヒープまたはクラスター化テーブルのどちらに格納されているかによって異なります。The structure of the row locator depends on whether the data pages are stored in a heap or a clustered table. ヒープに格納されている場合、行ロケーターは行を指すポインターです。For a heap, a row locator is a pointer to the row. クラスター化テーブルに格納されている場合、行ロケーターはクラスター化インデックス キーです。For a clustered table, the row locator is the clustered index key.

    • 非キー列をリーフ レベルの非クラスター化インデックスに追加することで、既存のインデックス キーの制限を回避して、すべてを対象とするインデックスが設定されたクエリを実行できます。You can add nonkey columns to the leaf level of the nonclustered index to by-pass existing index key limits, and execute fully covered, indexed, queries. 詳細については、「 付加列インデックスの作成」を参照してください。For more information, see Create Indexes with Included Columns. インデックス キーの制限の詳細については、「SQL Server の最大容量仕様」を参照してください。For details about index key limits see Maximum Capacity Specifications for SQL Server.

クラスター化インデックスと非クラスター化インデックスは共に一意インデックスにできます。Both clustered and nonclustered indexes can be unique. つまり、2 つの行がインデックス キーに同じ値を持つことができなくなります。This means no two rows can have the same value for the index key. 一意インデックスにしない場合、インデックスは一意でなくなり、複数の行が同じキー値を共有できます。Otherwise, the index is not unique and multiple rows can share the same key value. 詳細については、「 一意のインデックスの作成」を参照してください。For more information, see Create Unique Indexes.

テーブル データが変更されるたびに、テーブルまたはビューのインデックスが自動的にメンテナンスされます。Indexes are automatically maintained for a table or view whenever the table data is modified.

特別な用途のインデックスのその他の種類については、「 インデックス 」を参照してください。See Indexes for additional types of special purpose indexes.

インデックスと制約Indexes and Constraints

PRIMARY KEY 制約と UNIQUE 制約がテーブル列に定義されると、インデックスが自動的に作成されます。Indexes are automatically created when PRIMARY KEY and UNIQUE constraints are defined on table columns. たとえば、UNIQUE 制約があるテーブルを作成すると、データベース エンジンDatabase Engine によって非クラスター化インデックスが自動的に作成されます。For example, when you create a table with a UNIQUE constraint, データベース エンジンDatabase Engine automatically creates a nonclustered index. PRIMARY KEY を構成した場合、クラスター化インデックスが既に存在しない限り、データベース エンジンDatabase Engine によって自動的に作成されます。If you configure a PRIMARY KEY, データベース エンジンDatabase Engine automatically creates a clustered index, unless a clustered index already exists. 既存のテーブルに PRIMARY KEY 制約を適用しようとしたときに、そのテーブルにクラスター化インデックスが既に存在する場合、SQL Server によって、非クラスター化インデックスを使用するプライマリ キーが適用されます。When you try to enforce a PRIMARY KEY constraint on an existing table and a clustered index already exists on that table, SQL Server enforces the primary key using a nonclustered index.

詳細については、「 主キーの作成 」および「 UNIQUE 制約の作成」を参照してください。For more information, see Create Primary Keys and Create Unique Constraints.

クエリ オプティマイザーでのインデックスの使用方法How Indexes are used by the Query Optimizer

インデックスを適切に設計すると、ディスク I/O 操作が減少し、使用するシステム リソースが少なくなります。その結果、クエリのパフォーマンスが向上します。Well-designed indexes can reduce disk I/O operations and consume fewer system resources therefore improving query performance. インデックスは、SELECT、UPDATE、DELETE、または MERGE の各ステートメントを含むさまざまなクエリで役立ちます。Indexes can be helpful for a variety of queries that contain SELECT, UPDATE, DELETE, or MERGE statements. SELECT Title, HireDate FROM HumanResources.Employee WHERE EmployeeID = 250 データベースのクエリ AdventureWorks2012AdventureWorks2012 について考えてみましょう。Consider the query SELECT Title, HireDate FROM HumanResources.Employee WHERE EmployeeID = 250 in the AdventureWorks2012AdventureWorks2012 database. このクエリが実行されるときに、クエリ オプティマイザーでは、データの取得に使用できる方法がそれぞれ評価され、最も効率的な方法が選択されます。When this query is executed, the query optimizer evaluates each available method for retrieving the data and selects the most efficient method. 選択される方法には、テーブルのスキャン、1 つ以上のインデックスのスキャン (存在する場合) などがあります。The method may be a table scan, or may be scanning one or more indexes if they exist.

テーブル スキャンを実行すると、クエリ オプティマイザーでテーブルのすべての行が読み取られ、クエリの条件を満たす行が抽出されます。When performing a table scan, the query optimizer reads all the rows in the table, and extracts the rows that meet the criteria of the query. テーブル スキャンでは、ディスク I/O 操作が数多く行われ、リソースが集中的に使用される可能性があります。A table scan generates many disk I/O operations and can be resource intensive. ただし、クエリの結果セットに大部分のテーブル行が含まれる場合などは、テーブル スキャンが最も効率的な方法になることがあります。However, a table scan could be the most efficient method if, for example, the result set of the query is a high percentage of rows from the table.

クエリ オプティマイザーでインデックスが使用されるときは、インデックス キー列が検索され、クエリで必要とされる行のストレージの場所が検索されて、一致する行がその場所から抽出されます。When the query optimizer uses an index, it searches the index key columns, finds the storage location of the rows needed by the query and extracts the matching rows from that location. 一般に、インデックスの検索はテーブルの検索よりも高速です。これは、テーブルとは異なり、多くの場合、インデックスでは各行にごく少数の列しか含まれず、行が既に並べ替え済みであるためです。Generally, searching the index is much faster than searching the table because unlike a table, an index frequently contains very few columns per row and the rows are in sorted order.

クエリ オプティマイザーでは、通常、クエリを実行するときに最も効率的な方法が選択されます。The query optimizer typically selects the most efficient method when executing queries. ただし、インデックスが使用できなければ、クエリ オプティマイザーではテーブル スキャンを使用する必要があります。However, if no indexes are available, the query optimizer must use a table scan. クエリ オプティマイザーが効率的なインデックスを選択できるように、環境に最も適したインデックスを設計および作成する必要があります。Your task is to design and create indexes that are best suited to your environment so that the query optimizer has a selection of efficient indexes from which to select. SQL ServerSQL Serverデータベース エンジン チューニング アドバイザー が用意されており、データベース環境の分析や適切なインデックスの選択に役立てることができます。provides the Database Engine Tuning Advisor to help with the analysis of your database environment and in the selection of appropriate indexes.

重要

インデックスの設計のガイドラインおよび内部構造の詳細については、「SQL Server インデックス デザイン ガイド」を参照してください。For more information about index design guidelines and internals, refer to the SQL Server Index Design Guide.