SQL Индексирование сервера - есть ли преимущества создания некластеризованного индекса для составных ключевых полей?

Question

У меня есть PK на двух полях в моей таблице (UtilityId, int & ACCT_NO varchar (100)) Я действительно не знаю, имеет ли порядок значение, но это код (сначала с UtilityId):

ALTER table AccountAddress
ADD CONSTRAINT [PK_AccountAddresses] PRIMARY KEY CLUSTERED (UtilityId,ACCT_NO)

Если я хочу сделать запрос к таблице по UtilityId, будет ли полезно создание индекса по UtilityId (возможно, мне не нужно этого делать, поскольку в системе определен PK - в силу того, что индексирование уже существует) ).

И наоборот, если я хочу сделать запрос к ACCT_NO, который является вторым полем в определении индекса, то будет ли создание индекса по ACCT_NO полезным или не очень?

Answer 1

Индекс "обычный" (SQL сервер "реляционный" AKA B-Tree +) является своего рода вектором. И векторный путь является составной частью всех столбцов в ключе в порядке списка ключей.

Эффективность поиска зависит от "способов", которые вы пытаетесь получить ваши данные. Например:

CREATE INDEX X ON T (A, B, C)

Будет эффективен для равных поисков в следующих случаях:

• A и B и C
• A и B
• A

Бат не будет эффективен для равных поисков:

• B
• C
• B и C

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

Если вы хотите выполнить запрос только по ACCT_NO, Вы можете создать специфицированный индекс c для улучшения производительности.

Эффективность индекса зависит от предикатов, которые есть в вашем запросе (предложение WHERE, предложение ON для объединений, HAVING, CASE…). Это называется "sargable" (поиск ARGument ABLE). Например, LIKE «% anyword%» никогда не может быть sargable, независимо от того, какой у вас индекс.