Поможет ли индекс покрытия, если поля уже проиндексированы индивидуально

Question

В базе данных SQL Server 2005 у меня есть много таблиц, подобных этой таблице Products

ProductID (PK)
ProductCategoryID (IX)
Description
Price
ExpiryDate
BreakableYN

... где есть первичный ключ, внешний ключ и множество других полей. Другой характеристикой этого типа таблицы является то, что во многих запросах используются только поля с 2 идентификаторами (ProductID, ProductCategoryID), например, Employees JOIN EmployeeProductJoin JOIN Products JOIN ProductCategories JOIN ProductDepartments.

Если ProductID и ProductCategoryID уже проиндексированы, стоит ли добавлять еще один индекс для ProductID, ProductCategoryID?

Я знаю, что, похоже, я спрашиваю, поможет ли добавление индекса покрытия, но я действительно спрашиваю: поможет ли индекс покрытия, если поля в этом индексе покрытия уже проиндексированы индивидуально .

Это небольшие таблицы определений, поэтому я не беспокоюсь о добавлении дополнительного времени к INSERT и т. Д.

Answer 1

Кластеризован ли первичный ключ? Если это так, то добавление нового индекса ничего не даст, поскольку индекс ProductCategoryID уже будет содержать значения ProductID, поэтому он эффективно «охватывает» оба столбца.

Answer 2

Да, может. Смысл покрывающего индекса заключается в том, что запрос может обслуживаться только индексом без необходимости доступа к таблице. Таким образом, вы включаете не только поля, по которым вы ищете, но и поля, которые вы хотите вернуть, и оптимизатор запросов может вообще не обращаться к таблице.

Вы, возможно, не имеете в виду "индекс покрытия", хотя ...

Answer 3

Короче говоря Да, это улучшит производительность запросов.

Используя индекс покрытия, все необходимые для запроса столбцы присутствуют в структуре данных индекса. Это означает, что серверу SQL требуется запросить только один индекс, чтобы предоставить результаты для вашего запроса.

Принимая во внимание, что при наличии сценария с несколькими столбцами, которые индексируются отдельно, для обслуживания этого запроса SQL Server, скорее всего, придется выполнять поиск / сканирование многочисленных индексов, а не только одного. Это, конечно, потенциально создает больше операций ввода-вывода.

Имеет смысл?

Answer 4

Да, это может помочь одним конкретным способом. Идея покрывающего индекса состоит в том, что он имеет несколько избыточных полей, которые вы используете в запросах. Если индекс может удовлетворить требования к данным запроса без необходимости выполнения запроса к базовой таблице, вы можете сэкономить на вводе / выводе, получая данные из индекса.

Если у вас есть два индекса, как показано выше, СУБД должна была бы попасть в таблицу, а также разрешить два поиска индекса.

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

Answer 5

Я определенно могу помочь, особенно если ваши описания большие. Было бы легко оценить и убедиться в этом. Этот новый индекс может быть намного меньше кластерного. Но вы хотите иметь этот узкий индекс только в том случае, если у вас есть очень важные запросы, которые нужно ускорить, несмотря ни на что.

Answer 6

Только планы запросов (с дополнительными индексами и без них, а также с таблицами, содержащими реалистичные суммы и виды данных) могут точно сказать, помогут ли дополнительные индексы; все дело в том, чтобы помочь оптимизатору запросов найти более разумный план, но вы можете пока только помочь, и вполне возможно, что , что может не найти нужный вам план (это всего лишь эвристика), позвольте мне попробуйте оптимизировать "двигатель", в конце концов). Вот почему так важно смотреть на планы запросов (и вам нужны реалистичные данные, потому что это обычно влияет на эвристику!).