, когда использовать многоуровневый индекс

Question

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

Course (course_code, course_name, course_leader) 
Module (module_code, module_name, module_leader, semester) 
Course_module (course_code, module_code) 
Lecturer (employee_id, employee_name, email, phone) 

можно сделать предположение о количестве строк и типов доступа. Я просто хочу знать, когда это право использовать первичный индекс вместо многоуровневого или вторичного индекса и т.д.

Answer 1

Сначала небольшая терминологическая осветления ...

Первичного индекс просто индекс под первичным ключом , Вторичным индексом является любой другой индекс. Таким образом, это ортогонально «простому» или «композиционному» (или «составному») или индексу «многоуровневый»): первичный индекс может быть или не быть составным, а вторичный индекс может быть или не быть составным.

---

Чтобы ответить на ваш вопрос ...

В зависимости от структуры базы данных (PKS, FKS и кластеризации) и запросов, которые вы собираетесь работать.

Например, структура базы данных может означать:

• Там, вероятно, будет составной индекс на Course_module {course_code, module_code}, чтобы поддержать его ПК.
• Скорее всего, будет указатель на Course_module {module_code} для поддержки FK.
• Если вы хотите cluster (ака. «Индекс-организации») курсов, основанных на course_leader, будет кластерный индекс {course_leader} .
• Etc, и т.д ...

Потребности Выполнение запросов может означать:

• Если вы хотите, чтобы найти курс с учетом course_name, только и индекс {course_name} нужен (для хорошей производительности) ,
• Если вы хотите найти курс с данными course_name и course_leader, то необходим составной индекс на {course_name, course_leader}.
• Если вы хотите, чтобы получить курсы, которые принадлежат к данным course_leader вам нужен индекс на {course_leader}, но если ваш ВЫБРАТЬ список содержит только course_name, вы могли бы рассмотреть covering запрос с композитным индексом {course_leader, course_name}.
• Etc, и т.д ...

Каждого дополнительный индекс снижает производительность INSERT/UPDATE/DELETE, поэтому дизайн индекса является балансирование между чтением и записью.

Все это связано со структурой B-Trees и тем, как они используются для удовлетворения различных операций с базой данных.Полная обработка этого вопроса действительно выходит за рамки какого-либо одной StackOverflow ответа, но если вы заинтересованы, я горячо рекомендую прочитать от начала до конца: Use The Index, Luke!

---

Некоторого DBMSes не поддерживает кластеризацию и большинство из них требуют, чтобы ключ кластеризации был равен PK. MS SQL Server - заметное исключение - вы можете сгруппировать данные по ключу, отличному от ПК.