Покрытие индексов, когда дополнительные столбцы однозначно определяются кластеризованным индексом

Question

Предположим, мне нужно обновить myTab из luTab следующим образом

update myTab
  set LookupVale = (select LookupValue from luTab B
                                       where B.idLookup = myTab.idLookup)

luTab состоит из 2 столбцов (idLookup (уникальный), LookupValue)

Что предпочтительнее: уникальный кластеризованный индекс для idLookup или индекс для idLookup и Lookupvalue вместе взятые? Будет ли какой-либо индекс покрытия в этой ситуации иметь значение?

(меня больше всего интересует SQL-сервер)

---

Эпилог:

Я выполнил следующие тесты Krips с 27M строками в myTab, 1,5M строками в luTab. Важнейшая часть, кажется, уникальность индекса. Если индекс указан как уникальный, обновление использует хеш-таблицу. Если он не указан как уникальный, то обновление сначала агрегирует luTab с помощью idLookup (Stream Aggegate), а затем использует вложенный цикл. Это намного медленнее. Когда я использую расширенный индекс, в SQL больше не предполагается, что это LookupValue является уникальным, поэтому он вынужден идти по гораздо более медленному маршруту цикла с вложенным циклом

Answer 1

Во-первых:

• Индекс покрытия всегда не кластеризован
• У вас всегда должны быть PK и кластеризованный индекс (по умолчанию они одинаковы для SQL Server)

2 понятия являются отдельными

Итак:

• Ваш PK (кластеризованный) будет idLookup, если это однозначно идентифицирует строку
• Индекс покрытия будет (idLookup) ВКЛЮЧЕНО (LookupValue)

Тем не менее:

• idLookup - это PK (кластеризованный), поэтому вам не нужен индекс покрытия
• кластеризованный индекс (PK) неявно «покрывает» характер кластеризованного индекса (просто, индекс - это данные на самом низком уровне)

Answer 2

Я создал ваши таблицы и загрузил всего несколько записей (около 50 поисков и 15 в myTab).

Тогда я попробовал различные варианты индекса. Поиск индекса на luTab всегда стоит 29%.

Интересным моментом является то, что если вы добавите в столбце LookupValue к индексу на luTab, план выполнения покажет два дополнительных шага после поиска индекса: агрегирование потока и утверждение. Хотя стоимость равна 0%, это может привести к увеличению объема данных.

Я также попробовал некластеризованный индекс только для idLookup и включил LookupValue в качестве «Включенного столбца». Таким образом, нет необходимости обращаться к страницам данных, чтобы получить этот столбец. Это может быть вариант для вас, хотя план выполнения не показывает ничего другого (но они также не имеют Агрегат / Утверждение потока).

-Krip