Alois2 KRS544. Я натыкался на эту страницу, но так и несмог ее прочитать. Перебрал все настроенные у меня кодировки, но увы.

2 Glory
авторНа рис.3 у нижнего ряда кубиков слева написано DATA что означает что это страницы данных
У верхнего ряда кубиков справа написано INDEX что означает что это страницы индекса.
Даже обидно выслушивать такие комментарии. Это было понятно с самого начала. Вопрос не в этом.
А вот в чем. Страницы с данными я вляются листьями кластерного индекса. Но они упорядочены по индексируемому полю. В примере из моего поста 1469029 строка занимает 7008 байтов. Допустим строковое поле занимает 1000 байтов. тогда на странице данных влезет 7 строк.
Вопрос: при вставке (в примере это последний ИНСЕРТ) строки серверу придется создавать новую страницу и ФИЗИЧЕСКИ перемещать строку с ID=3 на другую страницу. После чего на страницах промежуточного уровня заново сортировать данные, возможно опять с разбивкой страниц. Верно?
Это же до фига работы.
Нет не верно.. Сервер помещает в этом случае в страницы данных ссылку на новое место строки (point forward ), и следовательно, указатель на нее из не листьевого уровня не надо изменять.
С уважением, Алексей.

AloisПри помощи DBCC IND, DBCC PAGE и советов Kalen Delaney (SQL server magazine online) проделал эксперимент.
Результат.
2 страницы данных: 1:50 (содержит строки 1,2,3) 1:93 ( строки 4,5).

Далее
Т.е. вставляем между 1-ой и 2-ой строками.
Результат.
3 страницы данных: 1:37 (содержит только строку 1), 1:50 (строки 2,0,3) и 1:93 (строки 4,5).
Т.е. сервер добавил новую страницу и перенес данные снизу вверх. Страницы индекса не менялись (строк всего 6)

Теперь ясность есть. Самые худшие опасения подтвердились. Ну и зачем нужен этот кластерный индекс, помогающий в очень редких (для работы моих юзеров) случаях?

Так где тут "худшие опасения". Естественно, будет перенос данных, но не более одной стрницы - 8 КБ для сервера это 0 по времени при ЛЮБОМ размере таблицы. Вы же опасались перестройки нелистьевого уровня индекса, а его и не произошло.
С уважением, Алексей.

AloisОпасения, конечно, были не по этому примеру. Что будет, если в таблице с миллионом строк я проапдейчу кластерное поле половины строк? Думаю, что это не 0 по времени.
А на сколько страниц данных приходится одна страница промежуточного уровня индекса при условии, что тип индексируемого поля INT (4 байта)? Думаю, что одна страница будет содержать ссылки на чуть меньше 2000 строк. На один миллион строк данных (в моем примере это больше 330 тыс страниц) - 501 страница индекса нижнего нелистьевого уровня и скорее всего одна страница верхнего плюс IAM. Итого - 503. Это гораздо меньше, чем 330 тысяч.

Я для кластерного индекса выбираю, как правило, PK (Primary Key), тип данных Integer со свойством IDENTITY(1,1) и НИКОГДА не имею, описанную Вами ситуацию: PK никто и никогда не UPDATE-ит, а INDENTITY(1,1) гарантирует, что вставка будет только в конец.
С уважением, Алексей.

ChA Aleksey-Kдля кластерного индекса выбираю, как правило, PK (Primary Key), тип данных Integer со свойством IDENTITY(1,1)Загляните по ссылке , которую дал KRS544, есть подозрение, что Вам будет полезно ее просмотреть...

Спасибо прочитал, но не нашел там (если читать все обсуждение)противоречий с тем, что я сказал: (для кластерного индекса выбираю, КАК ПРАВИЛО, PK (Primary Key), тип данных Integer со свойством IDENTITY(1,1)). Нет правил без исключений.., но они (исключения) только подтверждают правила.
С уважением, Алексей.