Вопрос о значимости порядка поле в индексной ноде.

[HorrR]

Вопрос звучит следующим образом:
Играет ли роль порядок полей в индексной ноде таблицы или только их набор?

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

Косвенные доказательства в пользу этого утверждения:
1. После создания и заполнения индексной ноды поменять порядок полей невозможно(хотя добавить новые - запросто). Обычно, такая политика аксапты(не давать что-то изменить, например подкорректировать названия поля, сменив первую букву на заглавную) дает понять, что эти действия незначимы\не приведут к реальным изменениям.
2. В стандарте(4ка) есть очень мало таблиц(до 5ти, по-моему) у которых есть индексы с тем же набором полей, но в разном порядке, причем использование их под сомнением(скорее всего при миграции с 3ки).

Тем не менне, хотелось бы услышать ваши мнения.

[kashperuk]

Да, база данных будет использовать или не использовать индекс в зависимости от порядка полей в нем. Про это можно почитать в любой книге про базы данных.
Аксапта просто создает индекс на таблице в БД, поэтому к ней утверждение выше также относится.

[HorrR]

Цитата:

Аксапта просто создает индекс на таблице в БД

Вот это собственно и ответ. Спасибо.

[ansoft]

Однозначно играет! Чем выше поле которое разбивает таблицу на более крупные сегменты, тем быстрее поиск. Даты вроде рекомендуют ставить ниже, они тормозные.

Цитата:

После создания и заполнения индексной ноды поменять порядок полей невозможно

Причем поменять порядок можно легко... нет ничего невозможного... встаем на поле... удерживая Alt жмем стрелку вниз (вверх)... поле встает ниже (выше)...

[lev]

одно меленькое замечание. не надо забывать ещё и про встроенный оптимизатор БД. иногда вроде по всем параметрам индекс подходит под ваш запрос (и по составу, и по порядку), но запрос все равно тормозит. А происходит это потому, что оптимизатор посчитал лучшем (на основе своей статистики) взять другой, менее селективный индекс. Лечится соответственно обновлением статистики.

P.S. я имел опыт такого поведения в ORACLE.

[ansoft]

...в таком случае индекс назначается дерективой index
или фривольно index hint

[kashperuk]

Цитата:

Сообщение от ansoft

...в таком случае индекс назначается дерективой index
или фривольно index hint

Не совсем.
index просто отсортирует выборку в соответствии с полями, указанными в индексе
index hint порекомендует оптимизатору использовать именно указанный индекс

[lev]

Цитата:

Сообщение от ansoft

...в таком случае индекс назначается дерективой index
или фривольно index hint

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

[ansoft]

...во как... не знал.
Спасибо за интересную информацию, только непонятно почему сортировка будет выполнена по индексу и при этом сам индекс возможно не будет использован... странно... кроме того при использовании директивы index аксапта ругается (exception) если такого индекса нет...

[ansoft]

Согласен.

[lev]

Цитата:

Сообщение от ansoft

...в таком случае индекс назначается дерективой index
или фривольно index hint

кстати, про index и index hint уже обсуждалось вот здесь

[Владимир Максимов]

Цитата:

Сообщение от ansoft

...во как... не знал.
Спасибо за интересную информацию, только непонятно почему сортировка будет выполнена по индексу и при этом сам индекс возможно не будет использован... странно... кроме того при использовании директивы index аксапта ругается (exception) если такого индекса нет...

Сортировка будет выполнена не по индексу. Просто при конструировании запроса, посылаемого на сервер в директиве ORDER BY будут перчислены те поля, которые указаны в узле соответствующего индекса в Axapta.

К оптимизации запроса это не имеет никакого отношения. Это просто способ сокращенного написания ORDER BY. Соответственно, будет ругань, если такого индекса нет. Написали ключевое слово ORDER BY, а списка полей - нет.

А вот "index hint" - это как раз оптимизация. Точнее, рекомендация серверу по принципу "не будет ли любезен, многоуважаемый джин..." . Разумеется, "джин" может и отказаться.

Впрочему, "ручной тюнинг" (оптимизация) запросов при помощи хинтов, как правило, выходит "себе дороже". Лучше не использовать.

[Skvorcal]

А как лучше поступить в следующей ситуации...

Есть таблица, в таблице куча полей, но 99% запросов фильтруют данные по двум полям.
При этом 33% запросов фильтруют данные по одному полю, 33% запросов фильтруют данные по другому полю, а оставшиеся 33% запросов фильтруют данные по двум полям одновременно.

В такой ситуации лучше построить два отдельных индекса по каждому полю, или один индекс по двум полям?

[_scorp_]

Цитата:

Сообщение от Skvorcal

А как лучше поступить в следующей ситуации...

Есть таблица, в таблице куча полей, но 99% запросов фильтруют данные по двум полям.
При этом 33% запросов фильтруют данные по одному полю, 33% запросов фильтруют данные по другому полю, а оставшиеся 33% запросов фильтруют данные по двум полям одновременно.

В такой ситуации лучше построить два отдельных индекса по каждому полю, или один индекс по двум полям?

Создайте два индекса:
Индекс1
Поле1
Поле2

Индекс2
Поле2
Поле1

[AndyD]

Для того, что бы ответить на этот вопрос надо знать как распределены значения в ваших полях (или оценить заполнение таблицы в будущем). Не забывайте также, что в Аксапте в индексы неявно добавляется поле DataAreaId, если компании не отключены в таблице

Т.е., по крайней мере, общее количество строк в таблице, количество уникальных значений в полях, по которым выполняется выборка, а так же количество уникальных пар значений в этих полях.

Чем менее уникальны значения в полях, тем больше вероятность того, что оптимизатор предпочтет прямое сканирование таблицы

[Skvorcal]

Цитата:

Сообщение от AndyD

Для того, что бы ответить на этот вопрос надо знать как распределены значения в ваших полях (или оценить заполнение таблицы в будущем). Не забывайте также, что в Аксапте в индексы неявно добавляется поле DataAreaId, если компании не отключены в таблице

Т.е., по крайней мере, общее количество строк в таблице, количество уникальных значений в полях, по которым выполняется выборка, а так же количество уникальных пар значений в этих полях.

Чем менее уникальны значения в полях, тем больше вероятность того, что оптимизатор предпочтет прямое сканирование таблицы

А Вы не могли бы дать общие рекомендации, когда стоит делать два отдельных индекса по каждому полю, а когда стоит сделать один индекс сразу по двум полям?

У нас сейчас общее количество строк около 300 тыс, ежемесячный прирост около 15 тыс. Таблица по структуре чем-то напоминает PurchLine или SalesLine. Два поля - это идентификатор операции и идентификатор сущности, участвующей в операции (аналог PurchId и ItemId). Комбинация PurchId и ItemId уникальна. С одной стороны при открытии журнала операции система всегда делает выборку строк по идентификатору операции, с другой - пользователи регулярно строят отчеты по коду сущности и анализируют операции.

[_scorp_]

Цитата:

Сообщение от Skvorcal

У нас сейчас общее количество строк около 300 тыс, ежемесячный прирост около 15 тыс. Таблица по структуре чем-то напоминает PurchLine или SalesLine. Два поля - это идентификатор операции и идентификатор сущности, участвующей в операции (аналог PurchId и ItemId). Комбинация PurchId и ItemId уникальна. С одной стороны при открытии журнала операции система всегда делает выборку строк по идентификатору операции, с другой - пользователи регулярно строят отчеты по коду сущности и анализируют операции.

1. Для отображения на форме Вам нужен такой индекс.
SalesId
ItemId

При отображении данных на форме он подходит идеально. Сначала идет ограничение записей по SalesId, потом можно сортировать данные в форме по ItemId.

2. Если я правильно понял, то отчет будет что-то типа обороты по номенклатуре, с возможностью детализации оборотов по операциям. Посмотрите в сторону OLAP, задача ложится туда идеально и не надо никаких дополнительных индексов на эту таблицу, тем более что в нее происходит много вставок. Если же Вы все-таки решитесь строить такой отчет на OLTP данных AX, то здесь для ускорения работы отчета нужен индекс:
ItemId - для первой группировки по номенклатуры
SalesId - для второй группировки по операциям.

P.S. И вообще, конечно, отчеты лучше строить по проводкам.

[mazzy]

Цитата:

Сообщение от Skvorcal

А как лучше поступить в следующей ситуации...

Есть таблица, в таблице куча полей, но 99% запросов фильтруют данные по двум полям.
При этом 33% запросов фильтруют данные по одному полю, 33% запросов фильтруют данные по другому полю, а оставшиеся 33% запросов фильтруют данные по двум полям одновременно.

В такой ситуации лучше построить два отдельных индекса по каждому полю, или один индекс по двум полям?

Если у вас MS SQL...
и если в нем включено автосоздание индексов...
то ничего не делайте.

подождите немножко, а потом посмотрите что MS SQL насоздавал.
потом примете решение.

[Skvorcal]

Цитата:

Сообщение от _scorp_

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

Что-то типа того...

Цитата:

Сообщение от _scorp_

Посмотрите в сторону OLAP, задача ложится туда идеально и не надо никаких дополнительных индексов на эту таблицу, тем более что в нее происходит много вставок.

OLAP не подходит по двум причинам:
1. Слишком дорого и муторно разворачивать OLAP ради одного-двух отчетов.
2. Отчет является оперативным. Его формируют по нескольку раз в день и отслеживают тем самым исполнение операций. Плюс некоторое планирование...

Цитата:

Сообщение от _scorp_

P.S. И вообще, конечно, отчеты лучше строить по проводкам.

Отчеты лучше строить по тем таблицам, в которых содержиться максимум требуемой информации и обеспечивается максимальная скорость построения и достоверность данных. А проводки с трехэтажными джоинами или хитрыми комбинациями аналитик - это имхо на любителя...

Цитата:

Сообщение от mazzy

Если у вас MS SQL...
и если в нем включено автосоздание индексов...
то ничего не делайте.

подождите немножко, а потом посмотрите что MS SQL насоздавал.
потом примете решение.

А разве при очередном обновлении приложения (обновляем слоем, а не проектами) и последующей синхронизации словаря Аксапта не удалит все неаксаптовые индексы?

[AraraT®]

Цитата:

Сообщение от Skvorcal

...
А разве при очередном обновлении приложения (обновляем слоем, а не проектами) и последующей синхронизации словаря Аксапта не удалит все неаксаптовые индексы?

Может имелось ввиду:
http://msmvps.com/blogs/gladchenko/a...3/1311293.aspx

тогда можно на основе рекомендаций сделать индексы в АОТе.

Или есть еще какой-нибудь другой механизм?