インデックスに列を含めるための厳格なルール

非クラスター化インデックスに含める列とその順序を決定するための厳格なルールはありますか？私はちょうどこの投稿https://stackoverflow.com/questions/1307990/why-use-the-include-clause-when-creating-an-index を読んでいて、次のクエリでそれを見つけました：

SELECT EmployeeID, DepartmentID, LastName
FROM Employee
WHERE DepartmentID = 5

ポスターは、次のようなインデックスを作成することを提案しました。

CREATE NONCLUSTERED INDEX NC_EmpDep 
  ON Employee(EmployeeID, DepartmentID)
  INCLUDE (Lastname)

ここに、なぜこのようなインデックスを作成できないのかという質問があります

CREATE NONCLUSTERED INDEX NC_EmpDep 
      ON Employee( EmployeeID, DepartmentID, LastName)

または

    CREATE NONCLUSTERED INDEX NC_EmpDep 
          ON Employee( EmployeeID, LastName)
INCLUDE (DepartmentID)

そして、LastName列を含めることを決定するためにポスターを導くものは何ですか。他の列はなぜですか？そして、列をどの順序で保持するかをどのように決定するのですか？

marc_sによるインデックスの提案は間違っています。コメントを追加しました。（そして、それも受け入れられた私の答えでした！）

このクエリのインデックスは

CREATE NONCLUSTERED INDEX NC_EmpDep 
  ON Employee(DepartmentID)
  INCLUDE (Lastname, EmployeeID)

通常、インデックスは

CREATE INDEX <name> ON <table> (KeyColList) INCLUDE (NonKeyColList)

どこで：

• KeyColList =キー列=行の制限と処理に使用される
  WHERE、JOIN、ORDER BY、GROUP BYなど
• NonKeyColList =非キー列= SELECTおよび集約（例：SUM（col））で選択/制限後に使用

JNKとgbnは素晴らしい答えを出しましたが、単一のクエリに焦点を合わせるだけでなく、全体像を検討する価値もあります。この特定のクエリはインデックス（＃1）から恩恵を受けるかもしれませんが：

Employee(DepartmentID) INCLUDE (Lastname, EmployeeID)

次のようなクエリがわずかに変更される場合、このインデックスはまったく役に立ちません。

SELECT EmployeeID, DepartmentID, LastName
FROM Employee
WHERE DepartmentID = 5 AND LastName = 'Smith'

これにはインデックスが必要です（＃2）：

Employee(DepartmentID, LastName) INCLUDE (EmployeeID)

部門5に1,000人の従業員がいるとします。インデックス＃1を使用して、すべてのスミスを見つけるには、含まれる列がキーの一部ではないため、部門5の1,000行すべてを検索する必要があります。インデックス2を使用すると、部門5、LastName Smithに直接シークできます。

したがって、インデックス＃2はより広範なクエリの処理に役立ちますが、コストはインデックスキーが肥大化するため、インデックスの非リーフページが大きくなります。すべてのシステムは異なるため、ここには経験則はありません。

サイドノートとして、EmployeeIDがこのテーブルのクラスター化キーである場合（クラスター化インデックスを前提とする場合）、EmployeeIDを含める必要はありません。これは、すべての非クラスター化インデックスに存在します。なる

Employee(DepartmentID, LastName)

どうやって最初に手に入れたのかわかりません。私にとって、そのクエリには、次のものを使用します。

CREATE NONCLUSTERED INDEX NC_EmpDep 
  ON Employee(DepartmentID)
  INCLUDE (EmployeeID, Lastname)

SQLのほとんどすべてに「ハードで高速なルール」はありません。

しかし、あなたの例では、インデックスが使用するフィールドはDepartmentID、それがWHERE句の中にあるためです。

他のフィールドはそこから簡単にアクセスできる必要があります。あなたは、に基づいて選択DepartmentID後、INCLUDEインデックスのリーフ・ノードでこれらのフィールドがあります。

このインデックスでは機能しないため、他の例を使用したくありません。

電話帳のようなインデックスを考えてください。ほとんどの電話帳は、姓、名、ミドルネームの頭文字で並べられています。姓ではなく名を知っている場合、電話帳のインデックスの順序に基づいて名を検索できないため、電話帳は役に立ちません。

INCLUDEフィールドがなど、電話番号、住所、ブック内の各エントリのためのその他の情報のようなものです。

編集：

使用しない理由をさらに明確にするには：

CREATE NONCLUSTERED INDEX NC_EmpDep 
          ON Employee( EmployeeID, LastName)
INCLUDE (DepartmentID)

このインデックスは、どちらかEmployeeIDまたは両方が EmployeeIDありLastName、WHERE句にある場合にのみ役立ちます。これは、このクエリに必要なもののほとんど反対です。

まだ（employee_id、department_id）インデックスを使用できるかもしれませんが、whereフレーズに「ダミー」行を含める必要があります。たとえば、「employee_id = employee_id）

• （employee_id、departemnent_id）にインデックスがあります。
• department_idでのみ検索/制限する必要がある
• 間違った順序ので、インデックスを使用しません知っていない（または、物事が今では変更されている、および以下の「トリック」はもはや必要とされている。私は、「oldy」です？） 。

• 「古い」トリックを使用しますか？

  select * from Employee emp
  where emp.employee_id = emp.employee_id
  およびemp.department_id = 5
  

（だから私はここで姓のインクルード部分に焦点を当てるのではなく、キーのイエス/または使用されていないことに焦点を当てています。）

敬具、

ミゲル