|
30.08.2010, 14:10 | #1 |
Участник
|
Вопрос о значимости порядка поле в индексной ноде.
Вопрос звучит следующим образом:
Играет ли роль порядок полей в индексной ноде таблицы или только их набор? Решил уточнить, так как есть тень сомнения по этому поводу, хотя логика подсказывает, что только набор. Косвенные доказательства в пользу этого утверждения: 1. После создания и заполнения индексной ноды поменять порядок полей невозможно(хотя добавить новые - запросто). Обычно, такая политика аксапты(не давать что-то изменить, например подкорректировать названия поля, сменив первую букву на заглавную) дает понять, что эти действия незначимы\не приведут к реальным изменениям. 2. В стандарте(4ка) есть очень мало таблиц(до 5ти, по-моему) у которых есть индексы с тем же набором полей, но в разном порядке, причем использование их под сомнением(скорее всего при миграции с 3ки). Тем не менне, хотелось бы услышать ваши мнения.
__________________
Axapta has seduced me deadly! |
|
30.08.2010, 14:16 | #2 |
Участник
|
Да, база данных будет использовать или не использовать индекс в зависимости от порядка полей в нем. Про это можно почитать в любой книге про базы данных.
Аксапта просто создает индекс на таблице в БД, поэтому к ней утверждение выше также относится. |
|
30.08.2010, 14:27 | #3 |
Участник
|
Цитата:
Аксапта просто создает индекс на таблице в БД
__________________
Axapta has seduced me deadly! |
|
30.08.2010, 14:29 | #4 |
Участник
|
Однозначно играет! Чем выше поле которое разбивает таблицу на более крупные сегменты, тем быстрее поиск. Даты вроде рекомендуют ставить ниже, они тормозные.
Цитата:
После создания и заполнения индексной ноды поменять порядок полей невозможно
|
|
30.08.2010, 14:39 | #5 |
Ищущий знания...
|
одно меленькое замечание. не надо забывать ещё и про встроенный оптимизатор БД. иногда вроде по всем параметрам индекс подходит под ваш запрос (и по составу, и по порядку), но запрос все равно тормозит. А происходит это потому, что оптимизатор посчитал лучшем (на основе своей статистики) взять другой, менее селективный индекс. Лечится соответственно обновлением статистики.
P.S. я имел опыт такого поведения в ORACLE.
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
30.08.2010, 14:51 | #6 |
Участник
|
...в таком случае индекс назначается дерективой index
или фривольно index hint |
|
30.08.2010, 14:56 | #7 |
Участник
|
Цитата:
index просто отсортирует выборку в соответствии с полями, указанными в индексе index hint порекомендует оптимизатору использовать именно указанный индекс |
|
30.08.2010, 15:02 | #8 |
Участник
|
...во как... не знал.
Спасибо за интересную информацию, только непонятно почему сортировка будет выполнена по индексу и при этом сам индекс возможно не будет использован... странно... кроме того при использовании директивы index аксапта ругается (exception) если такого индекса нет... |
|
30.08.2010, 15:18 | #9 |
Участник
|
Цитата:
Сообщение от ansoft
...во как... не знал.
Спасибо за интересную информацию, только непонятно почему сортировка будет выполнена по индексу и при этом сам индекс возможно не будет использован... странно... кроме того при использовании директивы index аксапта ругается (exception) если такого индекса нет... К оптимизации запроса это не имеет никакого отношения. Это просто способ сокращенного написания ORDER BY. Соответственно, будет ругань, если такого индекса нет. Написали ключевое слово ORDER BY, а списка полей - нет. А вот "index hint" - это как раз оптимизация. Точнее, рекомендация серверу по принципу "не будет ли любезен, многоуважаемый джин..." . Разумеется, "джин" может и отказаться. Впрочему, "ручной тюнинг" (оптимизация) запросов при помощи хинтов, как правило, выходит "себе дороже". Лучше не использовать. |
|
30.08.2010, 14:58 | #10 |
Ищущий знания...
|
так же в БД могут быть отключены хинты, т.е. что базе не посылай, она будет все равно пользоваться своим оптимизатором, игнорируя все указания из вне.
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
30.08.2010, 15:04 | #11 |
Участник
|
Согласен.
|
|
30.08.2010, 15:04 | #12 |
Ищущий знания...
|
Цитата:
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
31.08.2010, 12:31 | #13 |
Участник
|
Для того, что бы ответить на этот вопрос надо знать как распределены значения в ваших полях (или оценить заполнение таблицы в будущем). Не забывайте также, что в Аксапте в индексы неявно добавляется поле DataAreaId, если компании не отключены в таблице
Т.е., по крайней мере, общее количество строк в таблице, количество уникальных значений в полях, по которым выполняется выборка, а так же количество уникальных пар значений в этих полях. Чем менее уникальны значения в полях, тем больше вероятность того, что оптимизатор предпочтет прямое сканирование таблицы
__________________
Axapta v.3.0 sp5 kr2 |
|
31.08.2010, 13:00 | #14 |
Участник
|
Цитата:
Сообщение от AndyD
Для того, что бы ответить на этот вопрос надо знать как распределены значения в ваших полях (или оценить заполнение таблицы в будущем). Не забывайте также, что в Аксапте в индексы неявно добавляется поле DataAreaId, если компании не отключены в таблице
Т.е., по крайней мере, общее количество строк в таблице, количество уникальных значений в полях, по которым выполняется выборка, а так же количество уникальных пар значений в этих полях. Чем менее уникальны значения в полях, тем больше вероятность того, что оптимизатор предпочтет прямое сканирование таблицы У нас сейчас общее количество строк около 300 тыс, ежемесячный прирост около 15 тыс. Таблица по структуре чем-то напоминает PurchLine или SalesLine. Два поля - это идентификатор операции и идентификатор сущности, участвующей в операции (аналог PurchId и ItemId). Комбинация PurchId и ItemId уникальна. С одной стороны при открытии журнала операции система всегда делает выборку строк по идентификатору операции, с другой - пользователи регулярно строят отчеты по коду сущности и анализируют операции. |
|
31.08.2010, 13:25 | #15 |
Участник
|
Цитата:
Сообщение от Skvorcal
У нас сейчас общее количество строк около 300 тыс, ежемесячный прирост около 15 тыс. Таблица по структуре чем-то напоминает PurchLine или SalesLine. Два поля - это идентификатор операции и идентификатор сущности, участвующей в операции (аналог PurchId и ItemId). Комбинация PurchId и ItemId уникальна. С одной стороны при открытии журнала операции система всегда делает выборку строк по идентификатору операции, с другой - пользователи регулярно строят отчеты по коду сущности и анализируют операции.
SalesId ItemId При отображении данных на форме он подходит идеально. Сначала идет ограничение записей по SalesId, потом можно сортировать данные в форме по ItemId. 2. Если я правильно понял, то отчет будет что-то типа обороты по номенклатуре, с возможностью детализации оборотов по операциям. Посмотрите в сторону OLAP, задача ложится туда идеально и не надо никаких дополнительных индексов на эту таблицу, тем более что в нее происходит много вставок. Если же Вы все-таки решитесь строить такой отчет на OLTP данных AX, то здесь для ускорения работы отчета нужен индекс: ItemId - для первой группировки по номенклатуры SalesId - для второй группировки по операциям. P.S. И вообще, конечно, отчеты лучше строить по проводкам. |
|
Теги |
индекс, как правильно |
|
Похожие темы | ||||
Тема | Ответов | |||
Вопрос по резервированию | 9 | |||
Поле mandatory, а 0 вставить нужно | 5 | |||
вычисляемое поле | 8 | |||
Где взять материалы и еще один конкретный вопрос | 6 |
Опции темы | Поиск в этой теме |
Опции просмотра | |
|