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

Существует ли какое-либо жесткое и быстрое правило для определения того, какие столбцы и в каком порядке следует размещать в Включенном в некластерный индекс. Я только что прочитал этот пост 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 (столбец)) после выбора / ограничения

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 было 1000 сотрудников. Используя индекс № 1, чтобы найти всех Смитов, вам нужно будет просмотреть все 1000 строк в Отделе 5, поскольку включенные столбцы не являются частью ключа. Используя индекс № 2, вы можете обратиться непосредственно к Отделу 5, LastName Smith.

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

В качестве примечания стоит отметить, что, если EmployeeID был ключом кластеризации для этой таблицы - при условии кластеризованного индекса - тогда вам не нужно включать EmployeeID - он присутствует во всех некластеризованных индексах, то есть индекс # 2 может просто быть

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),
• необходимость искать / ограничивать только по отделу
• зная, что он не будет использовать индекс с неправильного порядка (или теперь все изменилось, и следующий «трюк» больше не нужен. Я «старый»?) .

• Использовать «старый» трюк?

  выберите * из emp сотрудника,
  где emp.employee_id = emp.employee_id
  и emp.department_id = 5
  

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

С уважением,

Miguell