|
|
24.03.2008, 12:37
|
#1 |
|
Участник
|
CustInvoiceTrans кластерный индекс
Всем доброго времени суток!
Кто нибудь, подскажет, зачем в DAX4 понадобилось создавать кластерный индекс по RecId? Не приведет ли это к снижению производительности при массовой обработки накладных в заказах? Ведь в тройке индекс не был кластерным. Заранее спасибо за пояснения. |
|
|
|
24.03.2008, 12:38
|
#2 |
|
Участник
|
Кластерный индекс на таблице CustInvoiceTrans
|
|
|
|
24.03.2008, 12:52
|
#3 |
|
Участник
|
Создание кластерных индексов на крупных таблицах, вряд ли оправдано
|
|
|
|
24.03.2008, 12:59
|
#4 |
|
SAP
|
Цитата:
Кто нибудь, подскажет, зачем в DAX4 понадобилось создавать кластерный индекс по RecId?
|
|
|
|
| За это сообщение автора поблагодарили: Tarrash (1). | |
|
24.03.2008, 13:14
|
#5 |
|
Участник
|
А не может быть такой ситуации (пока теоретически).
Допустим первая обработка зарезервировала несколько десятков тысяч значений RecId. В это время другая обработка вставляет уже другие записи (RecId резервируется позднее). После этого вставляются с записи из первой обработки. Причем значения RecId будут меньше, чем из второй обработки. В результате перестроение кластерного индекса. Ведь резервирование RecId осуществляется средствами DAX-а а не SQL |
|
|
|
24.03.2008, 13:20
|
#6 |
|
Участник
|
Андре, дело в том что кластерные индексы оправданы в основном для редко изменяемых таблиц (это в основном справочники). И konopello абсолютно прав, если записи вставляются в СТРОГОМ порядке возрастания RecId то обновление кластерного индекса по RecId не приводит к большим затратам по производительности. Но вопрос, всегда ли записи будут вставляться СТРОГО по возрастанию RecId?
|
|
|
|
24.03.2008, 13:34
|
#7 |
|
Злыдни
|
Цитата:
Сообщение от Tarrash
дело в том что кластерные индексы оправданы в основном для редко изменяемых таблиц
|
|
|
|
24.03.2008, 13:38
|
#8 |
|
Участник
|
Yprit, примерно что-то подобное уже обсуждалось
Посмотрите, пожалуйста, Кластерный индекс на InventTrans в AX 4.0 |
|
|
|
25.03.2008, 08:57
|
#9 |
|
Участник
|
Цитата:
Сообщение от konopello
ну если подумать что recId теперь состоит с 64-бит и выделяется инкрементно, то проводки физически будет расположены в порядке их создания.
|
|
|
|
25.03.2008, 09:00
|
#10 |
|
Участник
|
Цитата:
Сообщение от Alexius
Это если в базе только одна компания.
|
|
|
|
25.03.2008, 09:18
|
#11 |
|
Участник
|
Цитата:
Сообщение от egorych
В 4 врое как RecId выделяется на таблицу без учета компании. Или я что-то путаю ?
|
|
|
|
24.03.2008, 13:09
|
#12 |
|
Moderator
|
Цитата:
Создание кластерных индексов на крупных таблицах, вряд ли оправдано
|
|
|
|
24.03.2008, 13:20
|
#13 |
|
Moderator
|
Цитата:
Не приведет ли это к снижению производительности при массовой обработки накладных в заказах?
|
|
|
|
24.03.2008, 13:29
|
#14 |
|
Участник
|
Спасибо за совет, Андре. Мы конечно погоняем тесты в разных варинатах, проанализируем планы выполнения запросов и т. п. и примем решение.
Но все равно интересно, почему именно для этой таблицы CustInvoiceTrans нужно было создавать кластерный индекс (прошу извинения за излишнюю дотошность). По InventTrans, например, нет кластерного индекса. |
|
|
|
24.03.2008, 13:51
|
#15 |
|
Злыдни
|
Tarrash, если ответить прямо на Ваш вопрос - потому что по BP максимально возможное число (если не все) таблицы в БД должны иметь кластерный индекс. В 4-ке попытались приблизиться к этому стандарту, правда не всегда обдуманно и удачно. В случае с CustInvoiceTrans - наверное, это не лучший выход, но ничего старшного в этом я тоже не вижу.
|
|
|
|
| За это сообщение автора поблагодарили: Tarrash (1). | |
|
24.03.2008, 14:01
|
#16 |
|
Moderator
|
Цитата:
по BP максимально возможное число (если не все) таблицы в БД должны иметь кластерный индекс
 Например, таблицы без кластерных индексов не подвержены не экстентовой дефрагментации, ни внутренней. И в случае массовой вставки/обновления/удаления - неиспользуемое пространство будет лишь дырами в страницах. И проблема будет даже не в разрастании БД, а в том, что для того, чтобы выполнить скан такой таблицы необходимо прочитать на порядок больше страниц, нежели необходимо.
|
|
|
|
24.03.2008, 14:08
|
#17 |
|
Злыдни
|
Цитата:
Сообщение от Андре
BP здесь не первоисточник.
 Можно обсудить, конечно, и преимущества куч перед кластреными индесами, и конкретные случаи выигрыша без использования кластерных индексов. Но это, скорее, для sql.ru уже. Поэтому я просто с Вами соглашусь Ну и ссылочку для комплектаhttp://www.microsoft.com/technet/pro.../clusivsh.mspx |
|
|
|
25.03.2008, 09:13
|
#18 |
|
Участник
|
Цитата:
Сообщение от Андре
Например, таблицы без кластерных индексов не подвержены не экстентовой дефрагментации, ни внутренней. И в случае массовой вставки/обновления/удаления - неиспользуемое пространство будет лишь дырами в страницах.
Насколько я представляю, таблица без кластерного индекса имеет внутренний уникальный 8-ми байтный ключ, последовательные значения которому присваивается при вставке записей и дефрагментация может возникнуть только при удалении записей, но не при вставке или обновлении. PS. Это все для MS SQL, хотя для Oracle должно быть что-то аналогичное |
|
|
|
24.03.2008, 14:20
|
#19 |
|
Moderator
|
Цитата:
Можно обсудить, конечно, и преимущества куч перед кластреными индесами, и конкретные случаи выигрыша без использования кластерных индексов.
|
|
|
|
24.03.2008, 15:23
|
#20 |
|
Moderator
|
А единственный (и основной) минус кластерного индекса состоит в том, что во всех некластерных индексах, вместо RowId хранится ключ кластерного индекса. Поэтому при выборке по некластерному индексу, фактически делается две выборки: Сначала выбираются значения ключей кластерного индекса из обычного индекса, затем по значениям этих ключей, выбираются записи из кластерного индекса. Так что я вот к рекомендации BP отношусь достаточно настороженно; Кластерный индекс однозначно лучше только в том случае, если процентов 70 выборок делается ТОЛЬКО по нему, а все остальные индексы используются только в каких-то экстремальных случаях.
|
|
|
Комбинированный вид
