Порядок столбцов в индексе - производительность вставки

Question

Я провел небольшое исследование по порядку столбцов индекса, но не уверен на 100%, поэтому, пожалуйста, несите меня на этом! У меня есть следующая таблица:

CREATE TABLE [Valuation] 
    ( 
     [ValuationID] [int] IDENTITY(1, 1) 
          NOT NULL 
          CONSTRAINT [PK_Valuation] PRIMARY KEY , 
     VersionID INT NOT NULL , 
     AlphanumericIdentifier VARCHAR(255) NOT NULL, 
     ... 
     other columns 
     ... 
    ) 

я много присоединяется к этой таблице другим на VersionID и AlphanumericIdentifier, поэтому я ставлю индекс на нем:

CREATE NONCLUSTERED INDEX [IX_Valuation] ON [dbo].[Valuation] 
(
[VersionID] ASC, 
[AlphanumericIdentifier] ASC 
) 

Два вопроса:

1. Эти объединения обычно выполняются для определенного идентификатора версии, поэтому это самый избирательный столбец и должен быть первым в индексе - правильно?
2. Вкладыши всегда выполняются для одной версии, что на 1 больше, чем у последней версии. Это должно уменьшить влияние производительности на вставки, поскольку вставленные строки являются «куском», который можно добавить в конец индекса. Это правильно?

Я уверен, что я прав 1, но 2 правильно?

Благодаря Джо

Answer 1

Да, вы правы, на обоих.

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

Добавление строк с добавочными значениями VersionID означает, что промежуточные страницы не нужно разделять.

Answer 2

на вопросы:

«Это присоединяется как правило, делается для конкретного VersionID, так что это самый селективный столбец и должен быть первым в индексе»

Соединения не имеют к этому никакого отношения, если только соединения не используются в качестве фильтра. Фильтры (предикаты предложения Where) и Sorting (Order By clauses) используют индексы. Будет ли использоваться индекс, зависит от того, сколько записей (строк) удовлетворяет фильтру. Если запрос вернет каждую строку в таблице (без предложения where), то, по всей вероятности, индекс не будет использоваться, поскольку оптимизатор запросов будет (правильно) решить, что он мог бы просто прочитать всю таблицу, чем попытаться использовать индекс. Индексы представляют собой иерархические древовидные структуры с несколькими уровнями. Использование индекса требует одного дискового ввода-вывода на индексный уровень для каждой строки, которая будет возвращена запросом. Поэтому, если запрос вернет все 1000 строк в таблице, а в индексе будет пять уровней, тогда для этого потребуется 5000 IO. Чтение данных непосредственно из таблицы, а не индекса, потребует только 1000 IO.

Далее, ваше заявление о «Это должно смягчить падение производительности на вставках как вставленные строки представляют собой„кусок“, который может быть добавлен в конце индекса»

Это утверждение верно только в том случае индекс является кластеризованным индексом. В вашей схеме кластеризованный индекс является основным ключом (потому что, хотя вы можете переопределить его, это поведение по умолчанию), которое находится на ValuationID, а не на VersionId. Поэтому вставки «кусков» любые записи, все ли они имеют одинаковые версииId или нет, будут добавлены в конце индекса, потому что все они будут иметь новые valuationId s.