Какой индекс sql использовать в моей таблице для лучшей производительности запросов

Question

У меня есть следующая таблица.Моя хранимая процедура всегда использует IitemId и диапазон дат создания. Где ItemId = ... and Created> ... and Created <.... </strong> Какой дизайн лучше всего подойдет для производительности.

У меня есть некластеризованный индекс на ItemId

CREATE TABLE [dbo].[LV] (
[Id]       UNIQUEIDENTIFIER NOT NULL,
[ItemId]   UNIQUEIDENTIFIER NOT NULL,
[C1]  NVARCHAR (7)     NOT NULL,
[C2] NVARCHAR (7)     NOT NULL,
[C3]  NVARCHAR (2)     NOT NULL,
[Created]  DATETIME2 (7)    NOT NULL,
CONSTRAINT [PK_LV] PRIMARY KEY CLUSTERED ([Id] ASC),
CONSTRAINT [FK_LV_Items_ItemId] FOREIGN KEY ([ItemId]) REFERENCES [dbo].[Items] ([Id]) ON DELETE CASCADE
);


GO
CREATE NONCLUSTERED INDEX [IX_LV_ItemId]
ON [dbo].[LV]([ItemId] ASC); 

Должен ли я добавлять индексы к ItemId и Created?Некластеризованный или кластеризованный?

Answer 1

Я согласен с ответом Таба (да, сгруппируйте его), но добавил бы, что для ужесточения вашего дизайна вы могли бы взглянуть немного глубже и рассмотреть вопрос о том, чтобы сделать его первичным ключом, а если нет, то почему бы и нет. За этой логикой стоит эта публикация переполнения стека

Answer 2

Для запроса, который вы имеете в виду, вы хотите составной индекс для (itemId, created).

Это работает, потому что условие на itemId является равенством, поэтому неравенство будет использовать второй ключ в индексе.

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

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

Answer 3

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