Хранимый файл может иметь один индекс, как в нашем рассмотренном случае тут: http://all4study.ru/bd/indeksirovanie-v-bazax-dannyx.html, и хранимый файл может иметь несколько индексов, который сделаны так что они могут быть раздельными или совместными. Если индексов полей два и более, то индекс может быть сделан по каждому полю отдельно, или может быть сделан совместный, так называемый составной индекс. Т.е когда идет комбинация полей, он называется составным.

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

Фактически будет две дополнительные колонки помимо идентификатора.
Комбинированный индекс в этом случае может работать при поиске по двум полям одновременно, либо по первому полю. Точнее так сказать: если индекс содержит несколько колонок, то он может хорошо использоваться по всем трем колонкам, по первым двум колонкам, и по первой колонке. По второй и третьей, или просто третьей искать нельзя. Т.е если индекс составной из трех колонок, то он хорошо используется по всем трем, с первой по вторую, и по первой колонке. Отдельно по второй колонке работать не может.

Особенности создания и применения индексов

1) В ряде СУБД размер составного индекса ограничивается. (размер – количество бит в строке). В SQL сервере 900 бит. С СУБД Oracle нельзя упорядочивать данные в нескольких колонках в разных направлениях(в некоторых СУБД можно, в некоторых нельзя). В Fox Pro можно создать составной индекс, данные в котором упорядочены в разных направлениях(одни по убыванию, другие по возрастанию). Но в Oracle только в одну сторону.

2) Для повышения производительности целесообразно размещать таблицы индексов в различных сегментах. Создаваемых на разных дисках. Тогда чтение и запись таблицы индексов может идти параллельно.

Надо отметить, что СУБД в процессе работы само принимает решение какой из индексов, имеющийся у таблицы использовать. Если индексов несколько, СУБД само подберет нужный индекс. Это происходит чаще всего на основе суммарной информации (распределения данных в таблице). Бывает случаи когда рассчитывается число различных значений индекса внутри индекса, отнесенных к среднему количеству записей (страниц). В колонке городов может быть записей 1000 а городов всего 10. На каждый город идет по 100 записей.

Информацию, на основе которой выбирают тот или иной индекс называют статистикой. В некоторых СУБД называют статистикой тенденции или эвристической статистикой, или статистикой эвристики. Но общее название это статистика, статистика расположения записей в той или иной таблице. Эти статистики не обновляются, с обновлением таблиц автоматически.Они добавляются периодически. На их обновление нужно время, нужно рассчитать все данные о таблицах и рассчитать дополнительную информацию, которая в базе данных храниться, чтобы потом можно было использовать тот или иной индекс. Фактически сбор этой статистики инициирует администратор специальными командами, которые есть у сервера, т.е есть команды которые заставляют сервер создавать статистики для всего подряд. Это администратор может делать во вне урочное время, если же таблицы слишком сильно подвержены изменению, то эти статистики могут запаздывать, и сервер будет выбирать не те индексы которые надо для поиска данных. Чем лучше работает администратор, чем чаще проводит статистику, тем лучше работает сервер по поиску записи.

В СУБД Oracle предусмотрена возможность сегментирования таблиц большого размера вместе с индексами. Получается локальный индекс на какую-то часть таблицы (его размер становиться меньше). При считывании данных считывается не весь индекс, который может быть большим, а только локальный, что повышает быстродействие.

Кроме того в СУБД Oracle предусмотрена возможность создания индекса с обратным порядком.Что позволяет избежать конкуренции за доступ к последней странице. Когда в базе данных, которая является файлом есть логический файл в каком то количестве. То фактически когда добавляются данные в таблицу, они не могут записаться где-то посередине файла, они все стремятся в конец файла при записи, в каждой таблице данные стремятся записаться в конец физического файла. В этом случае возникает конкуренция на ввод-вывод на последнюю страницу, но если сделать файл с обратным порядком, то некоторые таблицы могут пробиться в ту часть таблицы (особенно при кластерных индексах), где начальная сторона, и начало таблицы, если обратный порядок сделан, и таким образом конкуренция снижается. Тогда так называемый плотный индекс очень велик, и его считывание занимает достаточно большое время. Можно использовать многоуровневые или разряженные индексы. Что собственно сегодня и применяется.

Комментарии запрещены.