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

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

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


L>Именно это. Причем весьма убедительно.
M>>Кластерный индекс по identity крайне редко бывает оптимальным выбором, то есть это лучше чем отсутствие кластерного индекса вообще, но не более того..
L>Все, пошел звать Влада.
В чем вообще весь цымус кластерного индекса? Это механизм позволяющий с некоторой долей вероятности управлять физическим размещением записей в таблице. В случае кластеризации по identity бонусов с этого можно получить довольно мало.
Пусть у нас есть табличка с PK identity, идентификатором пользователя, и большим количеством других полей с данными.. Пусть каждый пользователь большую часть времени работает только со своими данными. Нагрузка достаточно высокая и данных надо обработать достаточно много.
Что получется, если мы кластеризуем таблицу по identity? Данные конкретного пользователя окажутся размазанными по всей таблице, записи нужные для обработки, с очень высокой вероятностью окажутся физически на разных страницах, что приведет к совершенно не нужному ползанью по диску. Пользователи постоянно мешали бы друг-другу при страничных локировках и latch'ах захватывая чужие данные...
А вот если бы мы кластеризовали эту таблицу по ID пользователя, то картина была бы совершенно другой, получилось бы, что каждый пользователь фактически работал бы со своей частью таблицы и не лез бы к соседу, большинство данных поднималось бы за одно обращение к диску, поскольку с хорошей вероятностью они все окажутся на одной странице, в крайнем случае на соседних...
Если бы у нас была еще и подчиненная таблица с отношением один ко многим, то опять таки, ровно из тех же соображений, кластеризовать ее бы стоило не по PK, а по внешнему ключу...
Это все к тому, что выбор кластерного индекса — крайне важный стратегический вопрос, и выбирать его надо исходя из предстоящей нагрузки и характерных запросов, и крайне редко оптимальным выбором является identity.


L>>>См. выше. Производительность с GUID будет хуже, чем int или bigint.
См. выше

Единственный недостаток GUID'а — это большая длинна, что уменьшает количество записей влезающих в одну страницу индекса и, как следствие, увеличивает количество обращений к диску при прохождении по B+tree индексу. Но, как я уже говорил, сколь-либо заметный эффект это оказывает на таблицах размером как минимум в десяток миллионов записей.