CustInvoiceTrans кластерный индекс

[Tarrash]

Всем доброго времени суток!

Кто нибудь, подскажет, зачем в DAX4 понадобилось создавать кластерный индекс по RecId? Не приведет ли это к снижению производительности при массовой обработки накладных в заказах?
Ведь в тройке индекс не был кластерным.
Заранее спасибо за пояснения.

[Tarrash]

Кластерный индекс на таблице CustInvoiceTrans

[AvrDen]

Создание кластерных индексов на крупных таблицах, вряд ли оправдано

[konopello]

Цитата:

Кто нибудь, подскажет, зачем в DAX4 понадобилось создавать кластерный индекс по RecId?

ну если подумать что recId теперь состоит с 64-бит и выделяется инкрементно, то проводки физически будет расположены в порядке их создания.

[Андре]

Цитата:

Создание кластерных индексов на крупных таблицах, вряд ли оправдано

Каким образом кластерность индекса зависит от размера таблицы и почему ?

[Tarrash]

А не может быть такой ситуации (пока теоретически).

Допустим первая обработка зарезервировала несколько десятков тысяч значений RecId.

В это время другая обработка вставляет уже другие записи (RecId резервируется позднее).

После этого вставляются с записи из первой обработки.
Причем значения RecId будут меньше, чем из второй обработки.
В результате перестроение кластерного индекса.

Ведь резервирование RecId осуществляется средствами DAX-а а не SQL

[Tarrash]

Андре, дело в том что кластерные индексы оправданы в основном для редко изменяемых таблиц (это в основном справочники). И konopello абсолютно прав, если записи вставляются в СТРОГОМ порядке возрастания RecId то обновление кластерного индекса по RecId не приводит к большим затратам по производительности. Но вопрос, всегда ли записи будут вставляться СТРОГО по возрастанию RecId?

[Андре]

Цитата:

Не приведет ли это к снижению производительности при массовой обработки накладных в заказах?

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

[Tarrash]

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

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

[Yprit]

Цитата:

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

дело в том что кластерные индексы оправданы в основном для редко изменяемых таблиц

Простите, а на чем основывается подобное заявление?

[Tarrash]

Yprit, примерно что-то подобное уже обсуждалось

Посмотрите, пожалуйста,

Кластерный индекс на InventTrans в AX 4.0

[Tarrash]

Yprit, вернее было бы сказать, индекс оправдан для, таблиц для которых значение ключа кластерного индекса монотонно возрастает/убывает или вставка записей в данную таблицу происходит достаточно редко. Прошу извинения, если не четко формулирую проблему. Но вопрос в другом: насколько ОПРАВДАН кластерный индекс ИМЕННО на таблице CustInvoiceTrans?

[Yprit]

Tarrash, если ответить прямо на Ваш вопрос - потому что по BP максимально возможное число (если не все) таблицы в БД должны иметь кластерный индекс. В 4-ке попытались приблизиться к этому стандарту, правда не всегда обдуманно и удачно. В случае с CustInvoiceTrans - наверное, это не лучший выход, но ничего старшного в этом я тоже не вижу.

[Андре]

Цитата:

по BP максимально возможное число (если не все) таблицы в БД должны иметь кластерный индекс

BP здесь не первоисточник. Например, таблицы без кластерных индексов не подвержены не экстентовой дефрагментации, ни внутренней. И в случае массовой вставки/обновления/удаления - неиспользуемое пространство будет лишь дырами в страницах. И проблема будет даже не в разрастании БД, а в том, что для того, чтобы выполнить скан такой таблицы необходимо прочитать на порядок больше страниц, нежели необходимо.

[Yprit]

Цитата:

Сообщение от Андре

BP здесь не первоисточник.

Ну, когда следование конкретному правилу BP в 90% случаях действительно является оправданным, то я обычно ссылаюсь на BP Можно обсудить, конечно, и преимущества куч перед кластреными индесами, и конкретные случаи выигрыша без использования кластерных индексов. Но это, скорее, для sql.ru уже. Поэтому я просто с Вами соглашусь Ну и ссылочку для комплекта

http://www.microsoft.com/technet/pro.../clusivsh.mspx

[Андре]

Цитата:

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

На всякий случай - мое сообщение выше - как раз наоборот: преимущества кластерных индексов. Дабы не ввести никого в заблуждение.

[fed]

А единственный (и основной) минус кластерного индекса состоит в том, что во всех некластерных индексах, вместо RowId хранится ключ кластерного индекса. Поэтому при выборке по некластерному индексу, фактически делается две выборки: Сначала выбираются значения ключей кластерного индекса из обычного индекса, затем по значениям этих ключей, выбираются записи из кластерного индекса. Так что я вот к рекомендации BP отношусь достаточно настороженно; Кластерный индекс однозначно лучше только в том случае, если процентов 70 выборок делается ТОЛЬКО по нему, а все остальные индексы используются только в каких-то экстремальных случаях.

[Yprit]

Цитата:

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

А единственный (и основной) минус кластерного индекса состоит в том, что во всех некластерных индексах, вместо RowId хранится ключ кластерного индекса

Ну и отлично, ведь кластерный индекс - это сами данные и есть

[fed]

Цитата:

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

Ну и отлично, ведь кластерный индекс - это сами данные и есть

Не совсем. В кластерном индексе тоже может быть несколько уровней у дерева. То есть - если у нас все индексы обычные, мы после сканирования получили список rowid и на доступ к каждой записи по rowid нам требуется ОДНО обращение к диску. В случае наличия кластерного индекса, если мы отсканировали обычный индекс, мы получили список ключей кластерного индекса. И потом для поиска каждой такой записи нам нужно минимум ДВА доступа к диску (вырожденный случай, когда у нас вся таблица влезла в одну страницу не рассматриваем). А если записей нас много - то и уровней в кластерном индексе может быть 3-4-5. Соответственно - поиск по обычному индексу занял 3 доступа к диску, а потом еще поиск по кластерному индексу занял 3 доступа к диску. Время поиска выросло почти в два раза...

[Yprit]

Цитата:

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

после сканирования получили список rowid

или список ключей кластерного индекса ДЛЯ СТРОК. Плюс не будем забывать о всяких хитрых алгоритмах read-ahead, которые работают только на кластерах. Плюс "метание" по страницам. И т.п.