ГлавнаяРазноеИндексы в бд

Индекс (базы данных). Индексы в бд


Индексирование в базах данных

Структура хранения на основе индексирования предполагает использовать двух хранимых файлов.1. Файл таблицы с данными (например, поставщиков деталей), его условно называют последовательный файл.2. Файл с индексами (например, данные о городах проживания поставщиков).

В файле с индексами названия городов всегда упорядочены по алфавиту. И фактически есть риды (RID) соответствующие записи файла поставщиков.

Например:Представим себе файл с данными, т.е таблица с поставщиками, там есть определенное количество записей. Риды S1,S2 и так далее.

В индексном файле записи упорядочены по алфавиту, а в файле с данными записи располагаются как есть.Они могут быть упорядоченны не по файлу городов, а по номеру или фамилии поставщика. Но нам допустим надо по городу. Файл городов в этом случае называется индексным файлом, состоящим из двух колонок. Ну а файл таблица (в физическом смысле файл, или в логическом смысле файл, как это в SQL серверах) называется индексированным .

Фактически для того чтобы найти сведения быстро в таблице, первоначально считывается индексный файл, он поскольку всегда состоит из двух колонок, то он может быть относительно малым (а таблица может быть достаточно широкой). Загружается в память (индексный файл). Так как записи упорядочены по алфавиту, то быстро находиться по алфавиту методом двоичного поиска( он быстрый). Когда у нас данные индексированы от маленького значения до большого, фактически первый раз ищется половина, смотрим попали или не попали. Если не попали, то следующую пополам, если не попали опять следующую и так далее. Всего надо 10 шагов чтобы в файле из 1024 записей в порядке возрастания, или убывания найти нужную запись. Если бы искали по порядку то в худшем случае оказалось бы 1024 поиска. Скорость поиска по индексному файлу очень велика, и чем больше записей тем быстрее, вместо последовательного поиска по всем записям нужной записи.

Иногда индексный файл называют инвертированным списком. Очень удобны такие инвертированные списки когда они делаются по ключевому полю, по Primary Key. Очень эффективны и быстро работают. В принципе могут быть две стратегии поиска поставщиков ,например, из города London. В файле поставщиков найти все записи, названия городов которых являются London.Или сначала в файле городов найти все значения с London, а затем по указателям найти записи. Во втором случае получается гораздо быстрее. Правда есть время, затрачиваемое на считывание файла городов. Если эти файлы соизмеримы то выигрыша нет, для маленьких табличек до 300 записей смысла индексы делать нет, потому что таблица с малым числом строк всегда загружается в виде страницы в память и что по индексу искать, что искать по памяти одинаково.

Если доля поставщиков из London очень мала, то такой файл эффективен (индексированный файл), если их доля велика то этот файл будет часто включаться, тогда выйгрыш от использования индексного файла начинает теряться. Индексы всегда хороши когда число искомых записей не превышает 10-15 процентов. Когда число искомых записей от 20% и выше то можно искать по прямому поиску.

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

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

Недостатки индексированияНедостаток использования индексов заключается в том, что если их много, то после обновления данных в таблицах(просто обновления, удаления, добавления записей) индексы должны перестраиваться. Чем больше индексов, тем больше перестроек. В руководстве SQL сервер говориться так : “на одну таблицу не более 16 идексов”. После 16 быстродействие не гарантируется, т.е до 16 индексов переиндексацию сервер обеспечивает относительно быстро, а дальше производительность сильно падает.

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

Индексы могут использоваться для двух целей: 1) для последовательного доступа. Например, найти всех поставщиков из города London.2) Для прямого доступа. Когда надо найти что-то конкретное.

all4study.ru

Индекс (базы данных) - Википедия

У этого термина существуют и другие значения, см. Индекс.

Индекс (англ. index) — объект базы данных, создаваемый с целью повышения производительности поиска данных. Таблицы в базе данных могут иметь большое количество строк, которые хранятся в произвольном порядке, и их поиск по заданному критерию путём последовательного просмотра таблицы строка за строкой может занимать много времени. Индекс формируется из значений одного или нескольких столбцов таблицы и указателей на соответствующие строки таблицы и, таким образом, позволяет искать строки, удовлетворяющие критерию поиска. Ускорение работы с использованием индексов достигается в первую очередь за счёт того, что индекс имеет структуру, оптимизированную под поиск — например, сбалансированного дерева.

Некоторые СУБД расширяют возможности индексов введением возможности создания индексов по столбцам представлений[1] или индексов по выражениям.[2] Например, индекс может быть создан по выражению upper(last_name) и соответственно будет хранить ссылки, ключом к которым будет значение поля last_name в верхнем регистре. Кроме того, индексы могут быть объявлены как уникальные и как неуникальные. Уникальный индекс реализует ограничение целостности на таблице, исключая возможность вставки повторяющихся значений.

Архитектура[ | ]

Существует два типа индексов: кластерные и некластерные. При наличии кластерного индекса строки таблицы упорядочены по значению ключа этого индекса. Если в таблице нет кластерного индекса, таблица называется кучей[3]. Некластерный индекс, созданный для такой таблицы, содержит только указатели на записи таблицы. Кластерный индекс может быть только одним для каждой таблицы, но каждая таблица может иметь несколько различных некластерных индексов, каждый из которых определяет свой собственный порядок следования записей.

Индексы могут быть реализованы различными структурами. Наиболее часто употребимы B*-деревья, B+-деревья, B-деревья и хеши.

Последовательность столбцов в составном индексе[ | ]

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

Например, представим себе телефонный справочник, отсортированный вначале по городу, затем по фамилии, и затем по имени. Если вы знаете город, вы можете легко найти все телефоны этого города. Однако в таком справочнике будет весьма трудоёмко найти все телефоны, записанные на определённую фамилию — для этого необходимо посмотреть в секцию каждого города и поискать там нужную фамилию. Некоторые СУБД выполняют эту работу, остальные же просто не используют такой индекс.

Производительность[ | ]

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

Ограничения[ | ]

Индексы полезны для многих приложений, однако на их использование накладываются ограничения. Возьмём такой запрос SQL:

SELECT first_name FROM people WHERE last_name = 'Франкенштейн';.

Для выполнения такого запроса без индекса СУБД должна проверить поле last_name в каждой строке таблицы (этот механизм известен как «полный перебор» или «полное сканирование таблицы», в плане может отображаться словом NATURAL). При использовании индекса СУБД просто проходит по B-дереву, пока не найдёт запись «Франкенштейн». Такой проход требует гораздо меньше ресурсов, чем полный перебор таблицы.

Теперь возьмём такой запрос:

SELECT email_address FROM customers WHERE email_address LIKE '%@yahoo.com';.

Этот запрос должен нам найти всех клиентов, у которых е-мейл заканчивается на @yahoo.com, однако даже если по столбцу email_address есть индекс, СУБД всё равно будет использовать полный перебор таблицы. Это связано с тем, что индексы строятся в предположении, что слова/символы идут слева направо. Использование символа подстановки в начале условия поиска исключает для СУБД возможность использования поиска по B-дереву. Эта проблема может быть решена созд

encyclopaedia.bid

Индекс базы данных • ru.knowledgr.com

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

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

Использование

Поддержка быстрого поиска

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

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

Индекс - любая структура данных, которая улучшает выполнение поиска. Есть многие отличающиеся используются с этой целью, и фактически существенная пропорция области информатики посвящена дизайну и анализу структур данных индекса. Есть сложные компромиссы дизайна, включающие выполнение поиска, размер индекса и выполнение обновления индекса. Много проектов индекса показывают логарифмический (O (регистрация (N))) выполнение поиска, и в некоторых заявлениях возможно достигнуть квартиры (O (1)) работа.

Охрана ограничения базы данных

Индексы привыкли к полицейским ограничениям базы данных, такой как УНИКАЛЬНЫЕ, ИСКЛЮЧЕНИЕ, ПЕРВИЧНЫЙ КЛЮЧ и ВНЕШНИЙ КЛЮЧ. Индекс может быть объявлен как УНИКАЛЬНЫЙ, который создает неявное ограничение на основной стол. Системы базы данных обычно неявно создают индекс на ряде колонок, объявленных ПЕРВИЧНЫМ КЛЮЧОМ, и некоторые способны к использованию уже существующего индекса полиции это ограничение. Много систем базы данных требуют, чтобы и ссылка и наборы, на которые ссылаются, колонок в ограничении ВНЕШНЕГО КЛЮЧА были внесены в указатель, таким образом улучшив исполнение вставок, обновления, и удаляет к столам, участвующим в ограничении.

Некоторые системы базы данных поддерживают ограничение ИСКЛЮЧЕНИЯ, которое гарантирует, что для недавно вставленного или обновленного отчета определенный предикат не держится ни для какого другого отчета. Это может использоваться, чтобы осуществить УНИКАЛЬНОЕ ограничение (с предикатом равенства) или более сложные ограничения, как обеспечение, что никакие диапазоны времени перекрывания или никакие объекты геометрии пересечения не были бы сохранены в столе. Индекс, поддерживающий быстро поиск отчетов, удовлетворяющих предикат, требуется, чтобы полиция такое ограничение.

Методы архитектуры/Индексации индекса

Несгруппированный

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

В несгруппированном индексе

  • Физический заказ рядов не то же самое как заказ индекса.
  • Индексируемые колонки - колонки типично непервичного ключа, используемые в СОЕДИНЕНИИ, ГДЕ, и ЗАКАЗ пунктами.

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

Сгруппированный

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

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

Группа

Когда к многократным базам данных и многократным столам присоединяются, это упоминается как группа (чтобы не быть перепутанным со сгруппированным индексом, описанным выше). Отчеты для столов, разделяющих ценность ключа группы, должны быть сохранены вместе в тех же самых или соседних блоках данных. Это может улучшить соединения этих столов на ключе группы, так как соответствующие отчеты сохранены вместе, и меньше ввода/вывода требуется, чтобы определять местонахождение их. Конфигурация группы определяет расположение данных в столах, которые являются частями группы. Группа может быть включена с индексом B-дерева или хеш-таблицей. Блок данных, где отчет стола сохранен, определен ценностью ключа группы.

Порядок следования столбцов

Заказ, в котором определение индекса определяет колонки, важен. Возможно восстановить ряд идентификаторов ряда, используя только первую индексируемую колонку. Однако это не возможно или эффективно (на большинстве баз данных) восстановить набор идентификаторов ряда, используя только вторую или большую индексируемую колонку.

Например, вообразите телефонную книгу, которая организована городом сначала, затем фамилией, и затем именем. Если Вам дают город, Вы можете легко извлечь список всех номеров телефона для того города. Однако в этой телефонной книге это было бы очень утомительно, чтобы найти все номера телефона для данной фамилии. Вы должны были бы посмотреть в части каждого города для записей с той фамилией. Некоторые базы данных могут сделать это, другие просто не будут использовать индекс.

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

Заявления и ограничения

Индексы полезны для многих заявлений, но идут с некоторыми ограничениями. Рассмотрите следующее заявление SQL:. чтобы обработать это заявление без индекса, программное обеспечение базы данных должно смотреть на last_name колонку на каждом ряду в столе (это известно как полное сканирование таблицы). С индексом база данных просто следует за структурой данных B-дерева, пока вход Смита не был найден; это намного менее в вычислительном отношении дорого, чем полное сканирование таблицы.

Рассмотрите это заявление SQL:. этот вопрос привел бы к адресу электронной почты для каждого клиента, адрес электронной почты которого заканчивается «@wikipedia.org», но даже если email_address колонка была внесена в указатель, база данных должна выполнить полный просмотр индекса. Это вызвано тем, что индекс построен учитывая, что слова идут слева направо. С групповым символом в начале критерия поиска программное обеспечение базы данных неспособно использовать основную структуру данных B-дерева (другими словами, ГДЕ-ПУНКТ не sargable). Эта проблема может быть решена посредством добавления другого индекса, созданного на и вопрос SQL как это:. это помещает групповой символ в самую правую часть вопроса (теперь gro.aidepikiw %), который может удовлетворить индекс на перемене (email_address).

Когда подстановочные знаки используются с обеих сторон слова поиска как %wikipedia.org %, индекс, доступный на этой области, не используется. Довольно только последовательный поиск выполнен, который берет O (N) время. Так, индекс должен быть доступным на колонках, на которых выполнен поиск.

Типы индексов

Индекс битового массива

Индекс битового массива - специальный вид индекса, который хранит большую часть его данных, поскольку бит выстраивает (битовые массивы) и отвечает на большинство вопросов, выполняя bitwise логические операции на этих битовых массивах. Обычно используемые индексы, такие как B+trees, являются самыми эффективными, если ценности, которые они вносят в указатель, не повторяют или повторяют меньшее число времен. Напротив, индекс битового массива разработан для случаев где ценности переменного повторения очень часто. Например, гендерная область в базе данных клиентов обычно содержит самое большее три отличных ценности: мужчина, женщина или другой. Для таких переменных у индекса битового массива может быть значительное исполнительное преимущество перед обычно используемыми деревьями.

Плотный индекс

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

Редкий индекс

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

Обратный индекс

Обратный ключевой индекс полностью изменяет значение ключа прежде, чем войти в него в индекс. Например, стоимость 24538 становится 83542 в индексе. Изменение значения ключа особенно полезно для индексации данных, таких как порядковые номера, где новые значения ключа монотонно увеличиваются.

Внедрения индекса

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

В Microsoft SQL Server узел листа сгруппированного индекса соответствует фактическим данным, не просто указателю на данные, которые проживают в другом месте, как имеет место с несгруппированным индексом. У каждого отношения могут быть единственный сгруппированный индекс и много несгруппированных индексов.

Контроль за параллелизмом индекса

К

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

Покрытие индекса

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

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

Рассмотрите следующую таблицу (другие области опущенный):

Чтобы найти Название ID 13, индекс на (ID) полезен, но отчет должен все еще быть прочитан, чтобы завоевать репутацию. Однако индекс на (ID, Имя) содержит необходимое поле данных и избавляет от необходимости искать отчет.

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

Стандартизация

Никакой стандарт не определяет, как создать индексы, потому что ISO Стандарт SQL не покрывает физические аспекты. Индексы - одна из физических частей концепции базы данных среди других как хранение (табличное пространство или filegroups). Продавцы RDBMS, которых все дают СОЗДАТЬ синтаксису ИНДЕКСА с некоторыми определенными вариантами, которые зависят от возможностей их программного обеспечения.

См. также

  • Индекс, захватывающий
  • Индекс (поисковая система)

ru.knowledgr.com