Является ли добавление второго столбца идентификатора полезным для индекса?

Question

Допустим, у меня есть таблица tbl_FacilityOrders с двумя внешними ключами fk_FacilityID и fk_OrderID в SQL Server 2005. Она может содержать заказы из нескольких сотен объектов.Мне нужно запросить отдельные записи, и мне будут доступны и идентификатор объекта, и идентификатор заказа.Лучше определить индекс по fk_FacilityID, а затем по fk_OrderID и передать оба запроса или просто использовать fk_OrderID.Поскольку идентификаторов объектов будет меньше, чем идентификаторов заказов, я мог бы убедиться, что отсеивание записей других пунктов сначала может быть полезным.

Второй вопрос: если бы я использовал вышеупомянутый запрос с двумя столбцами, соответствует ли порядок, в котором я пишу столбцы моего предложения WHERE, или достаточно ли умен движок, чтобы оценивать их в порядке индекса?

EG:

WHERE fk_facilityID = @FacilityID AND fk_OrderID = @OrderID

эквивалентно:

WHERE fk_OrderID = @OrderID AND fk_FacilityID = @FacilityID

?

Answer 1

Лучше определить индекс для fk_FacilityID, чем для fk_OrderID и передать оба запроса или просто использовать fk_OrderID.

Если OrderId уникально, то нет никакого реального преимущества в добавлении другого поля для данного сценария. Тем не менее, неплохо бы индексировать ваши FK, поскольку они всегда были ключом JOIN.

если бы я использовал запрос с двумя столбцами, приведенными выше, соответствует ли порядок, в котором я пишу столбцы моего предложения WHERE, или механизм достаточно умен, чтобы оценивать их в порядке индекса?

Нет, порядок здесь не имеет значения. Все, что имеет значение, это то, что наборы полей совпадают, то есть FieldA и FieldB находятся как в индексе, так и в предложении WHERE.

Порядок полей в индексе DOES имеет значение, хотя. Вы не можете использовать второе поле в индексе, не зная значения первого поля.

Answer 2

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

Чтобы ответить на ваш второй вопрос, два утверждения эквивалентны. SQL Server должен внутренне переупорядочить операторы для достижения оптимального плана выполнения ... однако вы всегда должны проверять сгенерированный план выполнения только для того, чтобы убедиться, что он ведет себя так, как вы ожидаете.