Индексы таблицы InventSettlement

[Kabardian]

Интересное мнение насчет индексов было у fed.

Цитата:

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

А это вообще не на аксаптовском уровне происходит. И даже не на уровне трейсинга SQL-операторов в SQL Profiler. Вот представь себе: У тебя есть таблица персонала. Есть куча индексов, один из которых по полю Пол. Ты говоришь - удалить сотрудника с employeeId=='Иванов И.И.'. Система находит по индексу emplIdIdx физический адрес записи и фетчит ее. Далее - надо удалить из всех индексов ключи, которые на эту запись ссылаются. Система рассчитывает значения индексных ключей (по данным из записи) и пытается найти и удалить все индексные ключи. Для этого она ПЕРЕБИРАЕТ все индексные ключи со значением равным вычисленному до тех пор, пока не наткнется на ключ, ссылающийся на нужную запись (то есть с сохраненным в индексном входе Row_Id==Row_ID нашей записи). Если индекс уникален, то этот перебор не требуется. Если относительно уникален (ну скажем - номер паспорта без серии) - то перебор будет недолгим. А вот если это индекс по полю типа Пол (два возможных значения) - перебор будет медленным и печальным. Собственно - по этому в книжках и не советуют строить индексы по полям с 2-5-10 возможными значениями - обновление такой индекс затормозит, а при выборке редко будет нужен. Но тем не менее - иногда приходится строить индексы по достаточно часто повторяющемуся полю. Даже если на каждое значение будет приходиться порядка 200-300 записей - все равно обновление тормозить будет изрядно.

Насколько я знаю - некоторые БД пытались решить эту проблему за счет того, что индекс подспудно сортировался по сочетанию ключ+физический адрес записи (ROW_ID). (То есть - значение ссылки на запись становилась некой виртуальной частью ключа). Однако - на практике это приводило к изрядным проблемам, поскольку приводило к усиленной перебалансировке дерева страниц при вставке новых записей. Кроме того - при реорганизации и упаковке таблиц, это усложняло перестроение индексов.
Так что - насколько я понимаю, в текущих версиях и SQL Server и Oracle используется именно такой подход к удалению ключей, который я описал...

[AndyD]

Цитата:

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

Интересное мнение насчет индексов было у fed.

Если почитать тему дальше, то видно, что это мнение, по крайней мере по отношению к MS SQL, было неправильное


2 Vadik
Если Cancelled входит в кластерный индекс, да еще на перевом месте (или на втором, после DataAreaId?), то имеет ли смысл добавлять его в другие индексы (на последнее место, правильно?)?

[Vadik]

Цитата:

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

Если Cancelled входит в кластерный индекс, да еще на перевом месте (или на втором, после DataAreaId?), то имеет ли смысл добавлять его в другие индексы ?

Вопрос хороший, правильный, и я бы даже сказал - философский. Теоретически - нет. На практике - при прочих равных условиях оптимизатор стабильно выбирает для index seek индекс с явно входящим в него Cancelled. Его в принципе можно понять - все же приятнее когда значения (пусть даже их всего два) ключевого поля (Cancelled) явно отсортированы а не лежат где-то "рядом" наподобие included. Так что я добавляю..

Цитата:

на последнее место, правильно ?

Предпочитаю строить некластерные индексы "правильно" (в соответствии с запросами) без оглядки на наличие и структуру кластерного - меньше шансов "нарваться" при его смене. Так как Cancelled используется практически всегда, добавляю его обычно одним из первых полей