Зачем нужен уникальный index, содержащий RecId?

[AndyD]

Цитата:

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

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

А почему вставка должна замедлиться?
Давай рассмотрим процесс?

Сначала, вставку куда получится

У нас есть 10тыс. уже вставленных значений индекса.
По ключу, мы хватаем первую страницу, но она уже заполнена (допустим, на страницу влазиет по 300 строк).
Ладно, хватаем следующую. Опять облом.
И так повторяем, пока не дойдем до последней (или берем ее сразу? Но тогда, как заполнять незанятое место?).

Получается, для предложенных условий, дергаем 34 страницы + количество уровней - 1 ( и это я еще не учел возможный переход по страницам верхних уровней). В самом оптимистическом случае количество страниц равно количеству уровней


Теперь, вставка при отсортированном Heap RID (или кластерном ключе)

Ну, тут очевидно, что открыто будет ВСЕГДА одно и тоже количество страниц, равное количеству уровней.

Ну и где здесь преимущество первого варианта?


По поводу окончания места в странице нижнего уровня.

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

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

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


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

[fed]

Если у тебя стоит FillFactor не равный 100, то есть большие шансы что подходящая страница будет найдена до просмотра всех страниц с данным ключем. Особенно если у нас индекс обновлялся и страницы малость фрагментированы и свободное место есть. При этом вероятность сплита (из за того что единственная нужная нам страница была на 100% заполнена и пришлось ее сплитить), в моем случае заметно меньше (потому что больше шансов найти страничку со свободным местом). А сплит страниц - штука трудоемкая. В максимально плохом случае может понадобится куда больше чм 34 страницы прочитать и прописать.

А еще - можно меня долго агитировать за советскую власть, но я тебе не поверю пока ты мне не расскажешь, как обеспечивается сортировка по RID данных для страниц ненулевого уровня Вот если у меня есть 10000 записей и 34 страницы с данным ключем, как мне при чтении страницы первого (то есть - первого не листового уровня) понять - в какую из листовых страниц мне вставлять очередную запись? То есть - правило железное: Если ты хочешь сортировать дерево по какому-то признаку, ты должен включить этот признак в ключ. Соответственно - для случая сортировки по RID страницы данных, нам надо этот RID включить в ключ данных и тащить на нелистовые страницы... Судя по тому, что я читал об индексах в SQL Server,в страницы 1ого и более высоких уровней, ключи кластерного индекса/RID данных не тянутся...