SAP R/3 форум ABAP консультантов

[Igor_34_rus]

Приветствую!

Будет ли влиять на скорость выборки порядок расположения полей в индексе БД?

Например:
БД = VBRP
вариант №1
1) MANDT Мандант
2) MATNR Номер материала
3) CHARG Номер партии
вариант №2
1) MANDT Мандант
2) CHARG Номер партии
3) MATNR Номер материала

Я думаю, что да, повлияет. Но хочется узнать мнение, как оно должно быть в теории.

Размышляю так:
При выборке по индексам, анализ записей идёт побитово(аналог binary search при read table). Соответственно, так как материала больше(одинаковых записей с этим полем много тысяч) системе придётся сравнивать большее количество второго поля.
Во втором примере, по партии(одинаковых полей около сотни, максимум) "отсекается" меньше кол-во записей для сравнения второго поля.... => выборка работает быстрее

[Armann]

Привет, в общем да, ты прав - в общем случае если записей с одинаковыми значениями материала больше чем с одинаковыми значениями партии - то второй индекс выгодней. Погугли определение 'селективность поля'

[alezhu]

А по моему одинаково и больше зависит от конкретных данных. Порядок в принципе один. Посмотрите Excel во вложении.
Допустим у нас 2 партии a1,a2 и 8 материалов b1-b8.
2 случая - когда индекс по партии-материалу и когда по материалу партии. Соответственно, расположение записей в Excel - сверху и снизу.
Допустим мы ищем партию a1, материал a7.
В обоих случаях мы найдем запись за 4 шага. Вроде одинаково.

Теперь допустим возьмем ту запись, что нашлась в первом случае(партия-материал) на самом первом шаге - это a1-b8 и попробуем ее найти в случае когда расположение - материал партия. Получается 4 шага вместо 1го.

А теперь сделаем наоборот - найдем запись в первом распределении, которая нашлась за 1 шаг на втором - это запись b4-a2. В первом распределении она находится за 2 шага.

Таким образом количество шагов зависит от конкретных данных, в однмо случае быстрее так, в другом так, в третьем вообще одинаково.

[Armann]

alezhu, это понятно что зависит от данных, но мы рассматриваем более менее конкретную ситуацию. У вас из 16 записей получается 2 партии и 8 материалов, а у Igor_34_rus - наоборот, 8 партий и 2 материала. Если взять ваши данные из экселя (16 записей) и поменять местами поля партия-товар (чтобы соответстовало условиям Igor_34_rus), то в таком случае при выборке с разными индексами:
Индекс материал-партия:
1. найдем 8 записей с указанным материалом
2. из 8 записей получим 1 запись с указанной партией

Индекс партия-материал:
1. найдем 2 записи c указанной партией
2. из 2 записей получим 1 запись с указанным материалом

Как видно, второй индекс здесь выгодней

P.S. а вашу таблицу с алгоритмом если честно не понял

[Удав]

Необходимо помнить, что отдельные индексы для каждого запроса никто делать не будет.
Поэтому порядок полей в индексе в первую очередь должен определяться частотой использования поля в выборках данных.
Если есть 10 запросов с использованием поля "материал" и 3 запроса - с комбинацией "материал-партия", то поле "MATNR" лучше поставить первым.
Если же принято решение, что номер партии - уникальный и не зависит от материала, то удобнее поле "CHARG" поставить выше.

Если какое-нибудь поле из середины индекса не используется при выборке, то возникает ситуация со skip scan, когда БД будет перебирать все ветки для пропущенного поля индекса.
И чем этих веток меньше, тем быстрее отработает запрос.
Поэтому при построении индексов также необходимо учитывать кардинальность(количество уникальных значений) для полей.

Но это - чистая теория. Оптимизатор СУБД - это "черный ящик".

[Igor_34_rus]

сделал тест

Последовательно запускал старый(мат-партия) индекс и новый(партия - мат.) - по пять раз.


Armann, материалов больше партий.

[Shvetz]

Не забывайте данные буферизуются в БД. Подобные замеры, что отображены на скриншоте, могут быть некорректными.

[alezhu]

[Кодер]

Поддержу Удава: везде говорится о том, что для построения индексов следует использовать поля, которые по факту чаще всего используются в большом количестве выборок или присутствуют в наиболее важной выборке.

2 alezhu: про структуру индекса почти так. Только вот все дело в том, что это сферический конь в вакууме. Это зависит от конкретной СУБД. Например оракл юзает B-tree для хранения индексов. И, как не странно, "B" там не binary, а balanced. Разделение от родительского узла до ветвей не обязательно по степени 2. Кроме того, при необходимости массовой выборки(когда считываются данные реально принадлежащие не одному листу индекса а нескольким) переход к др. листу выполняется без возврата к родительскому узлу за счет того, что листья хранят ссылку на соседние листья

[Armann]

[alezhu]

[Удав]