Жорстке і швидке правило для включення стовпців в індекс

Чи є якесь жорстке і швидке правило визначити, які стовпці та в якому порядку вони слід розміщувати Включено в некластеризований індекс. Я щойно читав цей пост 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 = Ключові стовпці = використовується для обмеження рядків та обробки
  БУДИ, ПРИЄДНАЙТЕСЬ, ЗАКАЗУЙТЕ, ГРУПУ ПО тощо
• 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)

Уявіть, що у вас було 1000 співробітників у відділі 5. Використовуючи індекс №1, щоб знайти усіх Смітів, вам потрібно буде пройти всі 1000 рядків у відділі 5, оскільки включені стовпці не є частиною ключа. Використовуючи індекс №2, можна звернутися безпосередньо до відділу 5, LastName Smith.

Таким чином, індекс №2 є більш корисним при обслуговуванні більш широкого спектру запитів - але вартість є більш роздутим індексним ключем, що зробить сторінки, що не містять листів, індексу. Кожна система буде різною, тому тут немає принципового правила.

В якості бічної примітки варто зазначити, що якщо EmployeeEID був ключем кластеризації для цієї таблиці - якщо припустити кластерний індекс - то вам не потрібно включати EmployeeID - він присутній у всіх некластеризованих індексах, тобто індекс №2 міг би просто бути

Employee(DepartmentID, LastName)

Я не впевнений, як у вас з’явився той перший. Для мене для цього запиту я використовував би:

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

Існує не "жорстке і швидке правило" для майже нічого в SQL.

Але, для вашого прикладу, єдине поле, яке використовуватиме індекс, це DepartmentIDтому, що воно знаходиться в WHEREпункті.

Інші поля просто повинні бути легко доступними звідти. Ви вибираєте, виходячи з DepartmentIDтогоINCLUDE має ці поля в аркуші аркуша індексу.

Ви не хочете використовувати інші ваші приклади, оскільки вони не працюватимуть для цього індексу.

Подумайте про індекс, як телефонну книгу. Більшість телефонних книг упорядковані Прізвищем, Іменем, Середнім Ініціалом. Якщо ви знаєте чиєсь прізвище, але не його прізвище, телефонна книга не приносить вам користі, оскільки ви не можете шукати ім'я на основі порядку індексу телефонної книги.

The INCLUDE поля, як номер телефону, адреса і т.д. інша інформація для кожного запису в книзі.

Редагувати:

Щоб додатково уточнити, чому не використовувати:

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

Цей показник є тільки корисним , якщо у вас є або EmployeeIDчи ОБИДВА EmployeeID і LastNameв вашому WHEREреченні. Це в значній мірі ОПОЗИЦІЯ того, що вам потрібно для цього запиту.

Я думаю, що ви все ще зможете використовувати індекс (служитель_id, відділ_id), але вам доведеться включати рядок "манекен" у фразу де, наприклад: "службовець_id = працівник_id"

• маючи індекс на (Employ_id, departemnent_id),
• шукати / обмежувати лише у відділі_id
• знаючи, що він не буде використовувати індекс, оскільки неправильний порядок (або все змінилося на сьогоднішній день, і наступний "трюк" більше не потрібен. Я "старий"?) .

• Використовуєте "старий" трікК?

  виберіть * із співробітника emp,
  де emp.employee_id = emp.employee_id
  та emp.department_id = 5
  

(Тому я не зосереджуюсь на включенні тут частини прізвища, а на так / або не використовуваний ключ.)

З повагою,

Мігель