Какова оптимальная стратегия индексации для таблицы отношений?

Таблица отношений является общим решением для представления отношения «многие ко многим» (m: n).Какова оптимальная стратегия индексации для таблицы отношений?

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

 
A  AtoB  B 
----  ----  ---- 
*id  *Aid  *id 
data  *Bid  data

Как она должна быть проиндексированы для обеспечения оптимальной производительности в каждой РЕГИСТРИРУЙТЕСЬ ситуации?

кластерный индекс по (Aid ASC, Bid ASC) (это обязательно так или иначе, я думаю)
вариант # 1 плюс дополнительный индекс по (Bid ASC, Aid ASC)
или вариант # 1 плюс дополнительный индекс по (Bid ASC)
любые другие варианты? Может быть, конкретный поставщик?

источник

2009-05-12 Tomalak

Хороший вопрос, спасибо. Я сделаю запись в своем блоге. – Quassnoi

Мой Google Reader скажет мне.:) – Tomalak

Ах, ты же другой парень! – Quassnoi

Я сделал несколько тестов, и вот обновление:

Чтобы охватить все возможные случаи, вам необходимо иметь:

CLUSTERED INDEX (a, b) 
INDEX (b)

Это будет охватывать все JOIN sutiations И ORDER BY

Обратите внимание, что индекс на B фактически сортируется по (B, A), так как он ссылается на кластерные строки.

До тех пор, пока ваши a и b таблицы имеет PRIMARY KEY «S на идентификаторы, вы сделать не необходимости создания дополнительных индексов для обработки ORDER BY ASC, DESC.

Смотрите запись в моем блоге для получения более подробной информации:

Indexing a link table

источник

2009-05-12 09:24:17 Quassnoi

Вам по-прежнему нужен индекс (B DESC) для использования индекса для ORDER BY b, DESC – Quassnoi

УКАЗАТЕЛЬ (b, a) не имеет преимущества? – Tomalak

ИНДЕКС (б) на самом деле является ИНДЕКСОМ (b, a, b), так как ваша таблица кластеризована. Индекс на (b, a) будет фактически индексом (b, a, a, b), который совершенно бессмыслен. – Quassnoi

Я думаю, что решение 2 является оптимальным. Я бы выбрал порядок кластеризованного индекса, посмотрев на значения и ожидая, какие из них имеют более четкие строки. Этот идет первым. Также важно иметь индексы unique или primary key на родительских таблицах.

В зависимости от СУБД номер 3 может работать как номер 2. Он может быть или не быть достаточно умным, чтобы рассматривать значения (ключ кластерного индекса) в некластерном индексе для чего-либо иного, кроме ссылки на фактическую строку. Если он сможет его использовать, то число 3 будет лучше.

источник

2009-05-12 09:24:13

Но какой * оптимальный? 1., 2. или 3.? :) Кроме того, вопрос более общий, чем конкретная проблема. – Tomalak

Tomalak: Я думал, вы имеете в виду всех их :) О, я не видел # 1 + ... Я бы выбрал номер 2. –

Хм, может быть, мне нужно переформатировать вопрос, чтобы сделать это более понятным. :) – Tomalak

Я сделал несколько быстрых и грязные испытаний путем изучения планов выполнения в сервере SQL 2005. планов показали, что SQL использует кластерный индекс для Aid, Bid для большинства запросов. Добавление индекса по Bid (ASC) показывает, что он используется для запросов типа

select * from A 
    inner join AtoB on Aid = A.id 
    inner join B on Bid = B.id 
where Bid = 1

Так я голосовавших за решение # 3.

источник

2009-05-12 10:01:46 edosoft

Вы ожидали, что @Quassnoi потратил время, чтобы отследить и объяснить. +1 в любом случае. :) – Tomalak

Какова оптимальная стратегия индексации для таблицы отношений?

ответ

Смежные вопросы