понимание структуры первичного ключа по нескольким столбцам

Question

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

Так что я понимаю, что b-tree-структура используется sql-сервером при индексировании.

Ниже приведен простой пример.

Day (Primary Key) Race Winner 
1     Dave 
2     Jill 
3     Jake 
… 
199     Jody 
200     Sam 

Таким образом, номер дня является нашим первичным ключом. На заднем плане используется структура, подобная приведенной ниже (или нечто подобное - только изображение, которое я нашел). Поэтому, если вы хотите запросить победителя гонки на 50-й день, я могу увидеть, используя приведенную ниже структуру, можно быстро найти, выполнив следующие действия:

Начать с корня> next 1 - 100> next 1 - 50 & then входит в лист 25-50, где я считаю, что он будет искать по строкам данные в этом листе, пока не найдет 50-й день. Является ли содержащееся здесь значение 50 & указателем на строку, которая содержит остальную часть данных в этой строке?

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

Date   ID SEC ID AutoID 
10th Jan 2015 ABC A123 1 
10th Jan 2015 ABC A344 2 
10th Jan 2015 DEF A123 3 
10th Jan 2015 GHJ A344 4 
20th Feb 2015 ABC A123 5 
20th Feb 2015 ABC A344 6 
20th Feb 2015 DEF A123 7 
20th Feb 2015 GHJ A344 8 

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

Здесь я теряюсь.

Как индексировать хранить эти данные и иметь возможность быстро восстановить их, как в первом примере? Ключевое значение «10th Jane 2015 ABCA123» на самом деле ничего не значит (я, вероятно, ошибочно предполагаю, что здесь происходит - я считаю, что индекс объединяет три столбца для создания уникального значения, которое он помещает в индексную таблицу) , В первом примере наше значение индекса фактически означало что-то для данных, т. Е. Число дней.

Я также не понимаю, как sql-сервер будет использовать AutoID? Когда вы запрашиваете данные выше, я бы использовал столбцы ID & в условии where, поэтому AutoID кажется бессмысленным?

Answer 1

Указано ли здесь значение 50 & указателем на строку, которая содержит остальную часть данных в этой строке?

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

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

В индексе с несколькими столбцами да, эффективно, что хранится в пределах уровней индекса, являются значениями из всех столбцов в сочетании. Вот почему с индексом с несколькими столбцами индекс действует только в том случае, если для критериев поиска используются самые левые n столбцы индекса (n < = количество столбцов в индексе).

В вашем втором примере, если индекс определен на Date, ID и SEC ID, в таком порядке, и у вас есть запрос с WHERE пунктом ID = 'ABC' то индекс попросту не может быть использована - потому что в первой части каждая клавиша - Date.