Как стать автором
Обновить

Как устроено индексирование баз данных

Уровень сложностиПростой
Время на прочтение12 мин
Количество просмотров101K
Всего голосов 53: ↑51 и ↓2+64
Комментарии9

Комментарии 9

Разве можно говорить "индексирование базы данных"?

Индексировать можно таблицу, а не базу

Ну .. в общем-то .. индексированной может быть и вся БД, более того, она может состоять исключительно из индексов, без таблиц! Для примера всё тот же mumps, он же более современный Cache и ряд иных реализаций. Хранение в разреженных сбалансированных деревьях, то что "доктор прописал" для B-tree индексов. Код применяется много где, насколько понимаю мало изменился с момента его создания в 1979году одним хирургом .. кажется. Даже не программистом. :)

Жаль, что автор статьи не сделал сноску на mumps, но это перевод.. какие претензии? ;)

В статье говорится только о таблицах реляционных БД

одним хирургом .. кажется. Даже не программистом. :)

Если вы про Octo Barnett, то как-то вы преуменьшили заслуги основателя и главы Computer Science Lab в Harvard School of Medicine :) Конечно, у него была и медицинская степень, и он даже практиковал, но он больше занимался computer science (первое образование у него именно в этой области), и, по сути, он один из основателей Medical Informatics, и именно в этой области все его основные работы. Упомянутый вами код, кстати, тоже несколько человек писали, из его его лаборатории. Вполне себе обычные выпускники MIT в CS, ни разу не врачи.

MUMPS это типичная айтишная история, только PO был на практике знаком с медициной.

И история успешная, спустя полвека она вполне живёт и развивается. Кажется, так долго прожить получилось только у лиспа и C :)

Это было давно, память уже подводит, Вы правы конешно же.. В ней, собственно и остался только ужас изучения mumps, и то, что весь синтаксис умещался на шпаргалку формата А4.. ;)

Плохо. Совсем непонятно, как работает hash-индексирование.

Ну и, например, какой же тип индексирования у MS SQL для числовых и строковых полей?

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

Потому для новичков укажу несколько отправных точек, знающие люди могут дополнить:
0) В большинстве случаев используют btree индекс. Он поможет и для поиска по "равно", и для поиска "больше" / "меньше", и для префиксного поиска LIKE 'some%'
1) Индексировать стоит только не поля, по которым идет частая выборка. Много индекcов = плохо, т.к. при каждом insert / update идет перестройка индексов и запись на диск;
2) Даже если создан индекс на поле, он может быть игнорирован планировщиком - или реально проще сделать фулл-аксесс, или статистика по полю устарела;
3) Если в запросах часто используется поиск по связке полей, то и индекс стоит сделать на эту связку полей. Чаще всего планировщик использует только 1 индекс (но есть исключения).
4) Во многих бд есть условные индексы, которые индексируют только некоторый срез данных. Например, если идет поиск вида: select ... from ... where deleted = 0 and status = x то условный индекс на поле status where deleted = 0 может быть более эффективным нежели просто на status.
5) Когда создали индексы, анализируйте планы запросов, смотрите, используются ли реально ваши индексы. Если индексы не используются и висят мертвым грузом - удаляйте.

Ну и самое важное, проверяйте все на практике.

Ну я ничего нового не узнал (этого всего я не знал, но не запомнить).

Зарегистрируйтесь на Хабре, чтобы оставить комментарий