Являются ли эти индексы взаимоисключающими?

Question

У меня есть база данных SQL 2008, которую я пытаюсь настроить, и я использовал некоторые образцы, которые я нашел для создания рекомендуемых индексов из представлений управления данными SQL.

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

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

CREATE INDEX [IX_FactBilling_FiscalPeriodKey1] 
    ON [ClearViewDev].[Performance].[FactBilling] ([fiscalperiodkey]) 
    include ([TotalReceived], [ExchangeRateTimeKey], [MatterKey], [BillingTypeKey] 
, [CurrencyKey], [PersonKey], [CompanyKey], [OfficeKey], [PracticeGroupKey], 
[ProfitCenterKey], [PersonnelTypeKey], [RankKey]) 

CREATE INDEX [IX_FactBilling_FiscalPeriodKey2] 
    ON [ClearViewDev].[Performance].[FactBilling] ([fiscalperiodkey]) 
    include ([TotalBilled], [ExchangeRateTimeKey], [MatterKey], [BillingTypeKey], 
[CurrencyKey], [PersonKey], [CompanyKey], [OfficeKey], [PracticeGroupKey], 
[ProfitCenterKey], [PersonnelTypeKey], [RankKey]) 

CREATE INDEX [IX_FactBilling_FiscalPeriodKey3] 
    ON [ClearViewDev].[Performance].[FactBilling] ([fiscalperiodkey]) 
    include ([TotalBilled], [TotalReceived], [MatterKey], [BillingTypeKey], 
[TransactionDateKey], [BusinessProcessInstanceDateKey], [PersonKey], 
[CompanyKey], [OfficeKey], [PracticeGroupKey], [ProfitCenterKey], 
[PersonnelTypeKey], [RankKey], [BillableHoursBilled], [BillableValueBilled], 
[StandardValueBilled], [HoursBilled]) 

Answer 1

Строго ответить на вопрос:

1. TotalReceived, ExchangeRateTimeKey, MatterKey, BillingTypeKey, CurrencyKey, PersonKey, CompanyKey, OfficeKey, PracticeGroupKey, ProfitCenterKey, PersonnelTypeKey, RankKey

2. TotalBilled, ExchangeRateTimeKey, MatterKey, BillingTypeKey, CurrencyKey, PersonKey, CompanyKey, OfficeKey, PracticeGroupKey, ProfitCenterKey, PersonnelTypeKey, RankKey

3. TotalBilled, TotalReceived, MatterKey, BillingTypeKey, TransactionDateKey, BusinessProcessInstanceDateKey, PersonKey, CompanyKey, OfficeKey, PracticeGroupKey, ProfitCenterKey, PersonnelTypeKey, RankKey, BillableHoursBilled, BillableValueBilled, StandardValueBilled, HoursBilled

Индекс 1 и 2 такие же, за исключением того, для первого поля (TotalReceived - TotalBilled). Индекс 3 отличается от 1 и 2. Теоретически запрос, который требует TotalBilled, не покрывается индексом 2, а запрос, который требует TotalReceive, не покрывается индексом 1. Но все теоретически.

Никто в здравом уме не захочет добавить эти 3 индекса. Они слишком широкие. То, что оптимизатор намекает вам, заключается в том, что на самом деле очень важно, чтобы FiscalPeriodKey был самым левым ключом в кластерном индексе. Во временных рядах лучшим выбором для кластеризованных ключей является клавиша времени, потому что временные ряды чаще всего запрашиваются для временных диапазонов. Увы, с таблицами фактов DW время составляет всего один из размеров запроса, часто другие запросы (например, география, организационная единица, семейство продуктов) также используются для запросов. И вы можете выбрать только один как кластерный ключ hte. Нажатие индекса индекса покрытия до предела для покрытия всех этих случаев приводит к огромному размаху данных и низкой производительности записи. В конечном счете, вы сталкиваетесь с осознанием того, что вы используете неправильный инструмент для работы.

Я бы порекомендовал вас исследовать модернизацию до columnstores. Все эти проблемы исчезнут, поскольку хранилище столбцов использует совершенно другой подход, а запросы получают от segment elimination. Конечно, для этого требуется, по крайней мере, SQL Server 2012 и рекомендуется SQL Server 2014 для updatable columnstores.

Более приемлемое решение - укусить пулю и развернуть куб SSAS. MOLAP процветает с такими проблемами, когда реляционный сервер просто не имеет ответа (по крайней мере, не до столбцов).

Без сгруппированных ключей.«ИД» является первичным ключом

Предполагаю, что вы имеете в виду, что «Идентификатор - это идентификатор, используемый в качестве первичного ключа и по умолчанию кластеризованный ключ». Если вы действительно имеете в виду, что у вас есть куча с некластеризованным первичным ключом ID, тогда вы заслуживаете проблем, которые у вас есть, и намного хуже.

Общепринятое решение проблемы, с которой вы сталкиваетесь (хорошо известно в отрасли под прописью 'index tipping point'), заключается в использовании корреляции между идентификатором и временем вставки. Для ограничения сканирования кластерного индекса используется таблица lookaside, в которой хранятся минимальные и максимальные идентификаторы для определенных временных диапазонов. См. Disposable Indexes для конкретного примера. Но корреляция существует только для одного измерения (времени), а не для других DW-измерений, поэтому вы возвращаетесь к тем же проблемам, что и выбор ключа кластеризованного индекса времени. Опять же, кубы SSAS или столбцовые магазины более подходят для задачи.