Стратегия индексирования SQL Server

Question

Я создаю веб-приложение с использованием SQL Server 2008, и у меня возникают трудности с лучшей стратегией индексации, учитывая наш прецедент. Например, большинство таблиц структурированы похоже на следующее:

CREATE TABLE Jobs 
(
    Id int identity(0, 1) not null, 
    CmpyId int not null default (0), 
    StatusId int not null default (0), 
    Name nvarchar(100) null, 
    IsDeleted bit not null default (0), 

    CONSTRAINT [PK_dbo.Jobs] 
     PRIMARY KEY NONCLUSTERED (Id ASC)) 

CREATE CLUSTERED INDEX IX_Jobs_CmpyIdAndId 
    ON Jobs (CmpyId, Id) 

CREATE INDEX IX_Jobs_CmpyIdAndStatusId 
    ON Jobs (CmpyId, StatusId) 

В нашем приложении, пользователи разделены на различные компании, что приводит к практически все запросы ищут подобные следующий:

SELECT * 
FROM Jobs 
WHERE CmpyId = @cmpyId AND ... 

Кроме того, рабочие места часто обращались с StatusId (аннулированы = -1, до = 0, = 1 открыт, назначается = 2, закрытые = 3), подобное приведенному ниже:

SELECT * 
FROM Jobs 
WHERE CmpyId = @cmpyId 
    AND StatusId >= 0 
    AND StatusId < 3 

Могу ли я лучше использовать составной кластерный индекс, как показано выше, или мне следует использовать кластерный индекс по умолчанию только для поля Id и создать отдельный индекс для CmpyId?

Для столбца StatusId, было бы правильным, если бы отфильтрованный индекс был бы способ пойти?

Я также рассматриваю разметку таблицы на CmpyId или StatusId, но не уверен, что было бы лучше (или если раздел не является лучшим).

Answer 1

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

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

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