powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Индексация таблиц. Логика работы на уровне БД?
5 сообщений из 5, страница 1 из 1
Индексация таблиц. Логика работы на уровне БД?
    #38139212
juventine
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый вечер! Задался вопросом логики работы индексации таблиц. Думаю, тема интересна не одному мне. Предлагаю обсудить и "родить" совместными усилиями истину.

Нет четкого понимания, как работает механизм индексации таблиц. Вот предположим у нас есть таблица, где первичным ключом будет автоинкрементированный суррогатный ключ id_key (1..100). Мы создаем на этом поле индексы. Так как данные в таблицах хранятся неупорядоченно ( реально в поле id_key, типа, рандомная, то есть начинается, к примеру, с 99, потом 44, 18, 1, 86 и т.д. ).
В общем, построили мы индексы. На уровне БД создается таблица, которая будет содержать два поля -- i_index и id_key. Только поле id_key будет теперь уже упорядочено. Например:

первичная таблица таблица, созданная на уровне сервера БД

i_index id_key ... другие поля i_index id_key

1 99 4 1

2 44 3 18

3 18 2 44

4 1 5 86

5 86 1 99


Имеем запрос к БД. Типа, в запросе будет фигурировать id_key в явном виде. Например, нужно вывести на экран некую инфу с id_key = 54.

Дальше, я так понимаю, сервер БД обращается к таблице с полями i_index и id_key ( второй случай ). И осуществляет двоичный поиск по полю id_key.

1,2,3,4,5 ...... 1..5 ...... 1...10 ...... <50 >50 50...60 ...... 50...55 ... 54
6,7,8,9,10 ..... 6..10 56...60

...... 11..15 ..... 11..20 60..70
...... 16..20 .....

...... ...... 21..30 .......
...... ...... 31-40 .......
...... 41-50 .......




То есть, как это работает. Наши сто записей разбиваются на две "категории" ( <50 и >50). Опа, у нас 54. Движемся дальше по дереву в "категорию" >50. Дальше попадаем в категорию 50...60.. О-па, 54 входит в этот диапазон. Идем дальше по дереву. О-па, попадаем в диапазон 50..55. О-па, и вот оно искомое 54! Ура!!!

По id_key мы определяем индекс нужной записи и по этому индексу обращаемся к нашей "родной" БД. Все чинно и благородно =))

В связи с этим вопросы:

1) верна ли моя логика рассуждений?

2) "Природа" того, что записи хранятся неупорядоченно в БД. Например, мы задаем поле автоинкрементируемым. Какого лешего в БД значения этого поля будут храниться неупорядоченно?

3) Зачем в принципе создавать индекс на суррогатный ключ, если мы можем сразу произвести поиск по суррогатному ключу в "родной" таблице?

4) При каком-то запросе именно по полю ПК мы ищем необходимый индекс или же я не прав?

5) Слышал мнение, что создание индексов позволяет избежать поиска информации по разным секторам винчестера? Мол, при создании индексов головка винчестера будет скользить по какому-то одному сектору диска. Можно поподробнее: за счет чего создание индексов решает эту проблему?

Как-то так..))

Огромное спасибо!
...
Рейтинг: 0 / 0
Индексация таблиц. Логика работы на уровне БД?
    #38139219
juventine
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Прошу прощения за некорректное отображение полей индекса и ПК. Выглядят так

первичная таблица таблица, созданная на уровне сервера БД

i_index id_key ... другие поля i_index id_key

1 99 4 1

2 44 3 18

3 18 2 44

4 1 5 86

5 86 1 99
...
Рейтинг: 0 / 0
Индексация таблиц. Логика работы на уровне БД?
    #38139220
juventine
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Опять тоже самое... ну да ладно... кто захочет, разберется =))
...
Рейтинг: 0 / 0
Индексация таблиц. Логика работы на уровне БД?
    #38139249
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У вас есть таблица
create table my_table (id_key int primary key, table_data some_data)
juventine На уровне БД создается таблица, которая будет содержать два поля -- i_index и id_key На уровне БД создается объект которым управляет сама СУБД (добавляет строки при добавлении записей, удаляет при удалении и т.д.) В простейшем виде это id_key, физический адрес строки.
juventine "Природа" того, что записи хранятся неупорядоченно в БД. Например, мы задаем поле автоинкрементируемым. Какого лешего в БД значения этого поля будут храниться неупорядоченно?Записи хранятся в блоках. СУБД будет вставлять данные туда где ей (СУБД) будет удобно. Это может быть соседний блок.
juventine Зачем в принципе создавать индекс на суррогатный ключ, если мы можем сразу произвести поиск по суррогатному ключу в "родной" таблице?Создавайте индекс на нужное поле. Получите сразу список физических адресов.
juventine При каком-то запросе именно по полю ПК мы ищем необходимый индекс или же я не прав?Глядя на запрос, оптимизатор СУБД решает какой индекс использовать.
juventine Слышал мнение, что создание индексов позволяет избежать поиска информации по разным секторам винчестера? Мнение неверное. Физический доступ к данным не ваша головная боль
...
Рейтинг: 0 / 0
Индексация таблиц. Логика работы на уровне БД?
    #38139430
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
juventineДобрый вечер! Задался вопросом логики работы индексации таблиц. Думаю, тема интересна не одному мне. Предлагаю обсудить и "родить" совместными усилиями истину.
Хм. А у Вас не было желания открыть документацию по используемой СУБД, как следует прочитать её и не "рожать в обсуждениях" абстрактного виртуального уродца?

juventineТак как данные в таблицах хранятся неупорядоченно ( реально в поле id_key, типа, рандомная, то есть начинается, к примеру, с 99, потом 44, 18, 1, 86 и т.д. ).
Не совсем. Если мы говорим об индексе по автогенерируемому первичному ключу, то записи в таблице обычно неплохо (хотя и не полностью) по нему упорядочены. Это же относится, например, к индексам по полям типа "дата создания записи". п

juventine1) верна ли моя логика рассуждений?
Ну как бы это сказать... в паре мест имеет некое отношение к реальности.

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

juventine3) Зачем в принципе создавать индекс на суррогатный ключ,
Затем, что без него сервер начнёт "умирать" на детских нагрузках.

juventine5) Слышал мнение, что создание индексов позволяет избежать поиска информации по разным секторам винчестера? Мол, при создании индексов головка винчестера будет скользить по какому-то одному сектору диска.
В документации Oracle есть такой замечательный раздел, "Концепции", с него крайне рекомендуется начинать знакомство с сервером. Уверен, в документации по другим СУБД есть что-то аналогичное.
...
Рейтинг: 0 / 0
5 сообщений из 5, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Индексация таблиц. Логика работы на уровне БД?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]