Содержание

Индексы - объект БД, повышающий производительность поиска данных

Индексы - быстро находить

Как содержание страниц в книге

Плюсы

  • В ОЗУ

  • Для поисковых операций

Минусы

  • много ОЗУ

  • Обновление индексов затратно

  • Вставка данных дольше

Когда нужно?

  • Чтение чаще, чем обновление

  • На те поля, что участвуют в поиске

  • Эксперименты показывают что производ улучшилась

  • Неизбежны на уникальных полях

  • На дочерних ключах FK

составные индексы на те поля по которым часто будет поиска (на 2 атрибута БД)

на состовном хорошо ищет и по 1му

IDX_nameAtribute

Когда не нужно?

  • маленткая таблица

  • часто выполняются INSERT, UPDATE

  • столбец содержит много null

  • столбцы которые часто обновляются

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

их куча и они математически сложные

Кластаризованные - используют PK - он не требует явного объявления и создаётся по умолчанию при определении ключа - оттсортирован по умолчанию

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

Двоичный поиск - эффективный алгоритм поиска записи в сортированном списке

Деление данных пополам - поиска далее в какой половине есть

для 8 найдёт максимум за 3

для 10000 за 14

для 1 000 000 за 20

log2(n)

По кол ву полей простые или составные

Уникальные и не уникальные

Первичные (уникальные), кластерные (может дублирование), не кластерные (большинство) может быть токо 1 кластенрный в табл

Партиционирование по индексам

Разряженные(диапозон) или плотные(большинство, каждую запись)

одноуровненые, многоуровневые(деревья)

покрывающие или непокрывающие (зависит от запроса) при той же таблице

B-tree сбалансирование (для запросов < или >, иди направо или налево)

T-tree всегда всё дерево в ОЗУ

R-tree (МП, поиск заправки, такси рядом)

Hash-table (идеально для поиска равенства, но < или > оч плохо)

индексы весят = бд

лучше пересоздавать раз в год

Действие

БД анализирует все возможные пути запроса, выбирая самый оптимальный

План выполнения запроса - возможный путь - последовательность операций для получения результата SQL запроса СУРБД (Реляционная СУБД)

Оптимизатор запросов - компонент СУРБД определяющий самый эффективный план запроса

Если в запросе есть поле под индексом - БД начнёт поиск с него

Можно делать индексы по несколькоим колонкам

Синтаксис

DROP INDEX index_name;