Как работают составные индексы? - PullRequest
58 голосов
/ 27 апреля 2009

Я создал составные индексы ( индексы для вас, математики) для таблиц ранее с предположением о том, как они работают. Мне было просто любопытно, верно ли мое предположение или нет.

Я предполагаю, что когда вы указываете порядок столбцов для индекса, вы также указываете, как индексы будут группироваться. Например, если у вас есть столбцы a, b и c, и вы указываете индекс в том же порядке a ASC, b ASC и c ASC, то результирующий индекс будет по существу многими индексами для каждой "группы" в a.

Это правильно? Если нет, то как будет выглядеть результирующий индекс?

Ответы [ 5 ]

66 голосов
/ 28 апреля 2009

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

Если вы определяете индекс для полей (a, b, c), записи сортируются сначала по a, затем по b, затем по c.

Пример:

| A | B | C |
-------------
| 1 | 2 | 3 |
| 1 | 4 | 2 |
| 1 | 4 | 4 |
| 2 | 3 | 5 |
| 2 | 4 | 4 |
| 2 | 4 | 5 |
30 голосов
/ 28 апреля 2009

Составной индекс похож на обычный алфавитный указатель в словаре, но охватывает две или более букв, например:

AA - page 1
AB - page 12

и т.д.

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

Его можно использовать при поиске по обоим столбцам ИЛИ по первому столбцу. Если ваш индекс такой:

AA - page 1
AB - page 12
…
AZ - page 245
BA - page 246
…

Вы можете использовать его для поиска по 2 буквам (= 2 столбцам в таблице) или как обычный индекс по одной букве:

A - page 1
B - page 246
…

Обратите внимание, что в случае словаря сами страницы располагаются в алфавитном порядке. Это пример индекса CLUSTERED.

В простом, не CLUSTERED индексе ссылки на страницы упорядочены, как в учебнике истории:

Gaul, Alesia: pages 12, 56, 78
Gaul, Augustodonum Aeduorum: page 145
…
Gaul, Vellaunodunum: page 24
Egypt, Alexandria: pages 56, 194, 213, 234, 267

Составные индексы также могут использоваться при ORDER BY двух или более столбцах. В этом случае может пригодиться предложение DESC.

См. Эту статью в моем блоге об использовании предложения DESC в составном индексе:

17 голосов
/ 28 апреля 2009

Наиболее распространенная реализация индексов использует B-деревья, чтобы обеспечить несколько быстрых поисков, а также достаточно быстрое сканирование диапазона. Здесь слишком много объяснений, но вот статья в Википедии о B-деревьях . И вы правы, первый столбец, который вы объявите в индексе создания, будет столбцом старшего разряда в результирующем B-дереве.

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

Если вы ищете все карточки для авторов, чья фамилия "Клеменс", вы просто идете в каталог авторов и очень быстро находите ящик с надписью "CLE-CLI" на передней панели. Это правильный ящик. Теперь вы выполняете неформальный бинарный поиск в этом ящике, чтобы быстро найти все карточки с надписью «Clemens, Roger» или «Clemens, Samuel».

Но предположим, что вы хотите найти все открытки для авторов, которых зовут "Самуил". Теперь вы в самом разгаре, потому что эти карты не собраны в одном месте в каталоге авторов. Подобное явление происходит с составными индексами в базе данных.

Разные СУБД различаются по тому, насколько умен их оптимизатор при обнаружении сканирования диапазона индекса и точной оценке их стоимости. И не все индексы являются B-деревьями. Вам нужно будет прочитать документы для вашей конкретной СУБД, чтобы получить реальную информацию.

4 голосов
/ 27 апреля 2009

Нет. Результирующий индекс будет одним индексом, но с составным ключом.

KeyX = A, B, C, D; KeyY = 1,2,3,4;

Индекс KeyX, KeyY будет фактически: A1, A2, A3, B1, B3, C3, C4, D2

Так что в случае, если вам нужно что-то найти по KeyX и KeyY - это будет быстро и будет использовать один индекс. Что-то вроде SELECT ... WHERE KeyX = "B" и KeyY = 3.

Но важно понимать: ГДЕ KeyX =? запросы будут использовать этот индекс, а WHERE KeyY =? НЕ будет использовать такой индекс вообще.

0 голосов
/ 31 августа 2017

Насколько я понимаю, составные индексы работают так же, как обычные индексы, за исключением того, что они имеют ключи с несколькими значениями. Если вы определяете индекс для полей (a, b, c), поскольку составной индекс будет храниться в BinaryTree, следовательно, ваш индекс будет работать только после следующих комбинаций поиска.

ABC
AB
A

Например, создание составного индекса для полей a, b и c эквивалентно созданию отдельных индексов для a, ab и abc.

...