Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Lexey, Вы писали:

M>Ладно, давай разбираться..

L>>Это тоже плохо, т.к. вставка с большой вероятностью будет приводить к лишним модификациям кластерного индекса.
M>Не совсем так... К модификациям кластерного индекса это не приведет, внутри страницы записи не упорядчены. А вот при частой вставке, при наличии монотонного

Откуда у тебя такие сведения. MS в BOL открытым текстом пишет, что clustered index задает физический порядок записей.

M> индекса возможет следующий любопытный эффект: При модификации индекса, в частности при добавлении нового ключа, для обеспечения согласованности, блокируется вся страница индекса, куда этот ключ добавляется. Блокировка (latch) накладывается только на время вставки и в обычном режиме сколь либо заметного эффекта на производительность она не оказывает, но если каждый последующий ключ больше (меньше) предыдущего, то все ключи попадают на последнюю страницу индекса и возникает драка за эту страницу между конкурирующими транзакциями и выстраивается совершенно не нужная очередь на ресурс. И ничего хорошего в этом нет. В случае же GUID'ов нагрузка размажется по всей таблице и чем больше таблица, тем меньше вероятность пересечения.

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

L>>Именно это. Причем весьма убедительно.
M>>>Кластерный индекс по identity крайне редко бывает оптимальным выбором, то есть это лучше чем отсутствие кластерного индекса вообще, но не более того..
L>>Все, пошел звать Влада.
M>В чем вообще весь цымус кластерного индекса? Это механизм позволяющий с некоторой долей вероятности управлять физическим размещением записей в таблице. В случае кластеризации по identity бонусов с этого можно получить довольно мало.

С некоторой долей вероятности? Это как?

M>Пусть у нас есть табличка с PK identity, идентификатором пользователя, и большим количеством других полей с данными.. Пусть каждый пользователь большую часть времени работает только со своими данными. Нагрузка достаточно высокая и данных надо обработать достаточно много.

Блин, я же тебе не предлагаю ВСЕГДА кластерировать по идентити. Но во многих реальных случаях выбока идет по id записи, которая как раз и есть identity. И кластерный индекс по identity тут самое то.
В твоем пример, кстати, с большой долей вероятности identity в таблице вообще будет не нужен.