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

VD>>Если заполнение последовательное, то кластыры набиваются довольно плотно и поиск по ним будет шустрый.
M>Поиск по кластеру более шустрый не из-за плотности заполнения — она всегда одинаковая, а из-за отсутствия bookmark lookups, ввиду того, что, как ты верно

С чего это она одинакова? При вставке в произвольнные места будет происходить дробление страниц, а это как раз понижение плотности. Плюс к этому индекс фрагментируется. Это может очень нефигово снижать производительность. При вставке в конец нет ни дробления ни фрагментации индекса.

M> заметил, нижние узлы индекса содержат сами данные, ну и из-за относительной физической упорядоченности.

VD>>2. Если на таблице есть кластерный индекс, то все ссылающиеся таблицы будут содержать в себе не что иное как значение ключа кластерного индекса.
M>Не таблицы, а другие индексы в этой таблице.

Это верно.

VD>>Без каких либо вероятностей. КИ — это гарантия что твои данные упорядочены физически.
M>Не совсем. Это гарантия того, что физически будут упорядочены страницы, а данные внутри страницы не упорядочены.

Тут ты возможно прав. Если будет время, попробую сам посмотреть.

VD>>3. Последовательное заполнение.
M>Вот последовательное заполнение я бы как раз в минус записал, я уже писал ранее почему.

Совсем не убедительно сказал.

VD>>А что ID-пользователя не может быть идентети? Ты что под этим термином понимаешь?
M>ID пользователя может быть любым, здесь я уже о том, что делать кластерный индекс по уникальному идентификатору вообще имеет мало смысла, не важно что это за идентификатор GUID или Identity.

Очень спорное утверждение.

VD>>Иначе любая ссылка будет букмарком, коий в скуле очень не хилый.
M>Не любая, а очень даже редкая.

Тут Влад действительно загнул.

VD>>Если бы. Его хаотичность — это куда более серьезная проблема.
M>Его хаотичность в большинстве случаев вообще не роляет.

Роляет, роляет.

VD>>Кстати, красиво ты опять перешел с ID-пользователя на гуиды. Так в чем кайф гуидов в твоем примере?
M>А читать внимательнее пробовал?

Я вроде внимательно читал и тоже не понял.

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

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

ОК, это серьезный аргумент.

L>>В описанное верится очень слабо.
M>Тем не менее это так.

Конкретный пример и цифры в студию, pls (если есть). Пока мой здравый смысл утверждает ровно обратное.

L>> Так же, скорее всего передраться могут только пишушие вставляющие транзакции (коих обычно гораздо меньше, чем читающих), а при вставке в середину еще придется драться с читателями.
M>А из последней страницы никто не читает? Как раз при кластеризации по identity к последней странце будут лезть все подряд.

С чего бы это? Последняя страница одна, а выборки по чтению идут по всем. Вероятность того, что понадобиться именно последняя страница порядка 1/N (N-число страниц). При больших N она ничтожна.

L>>С некоторой долей вероятности? Это как?
M>Так, что физического упорядочивания записи нет, есть упорядоченность страниц и гарантия того, что запись "меньше" самой "большой" и "больше" самой маленькой записи страницы окажется на этой странице.

ОК.

L>> И кластерный индекс по identity тут самое то.
M>Нет, не то, другие выборки, как правило, выполняются чаще и более критичны к скорости.

Опять голословный спор получается.

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

L>С чего бы это? Последняя страница одна, а выборки по чтению идут по всем. Вероятность того, что понадобиться именно последняя страница порядка 1/N (N-число страниц). При больших N она ничтожна.

Если в таблицу идут частые инсерты, то, при кластерном индексе по identity, вероятность того что потребуется последняя страница пропорциональна количеству вставляемых в секунду записей и обратно пропорциональна среднему размеру записи. И эта вероятность никак не зависит от числа страниц.

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

VD>Все так просто. Сделай эксперемент... Циклик в котором всавляй записи. Сначала с идентити, а потом с гуидами. Думаю, это тебя резко разубедит в своей правоте.

Guid долго формируется. Функция NewGuid() шифрует информацию о компьютере где был создан идентификатор, поэтому работает не очень быстро.

VD>Там эффект такой. Гуид дает очнь большой разбром. Такой большой, что практически каждый раз вставка будет идти в разные стрницы. Это приводит к тому, что на примитивную операцию нужно:
VD>1. Поднять практически всю таблицу в память.
Если бы это было так, то у меня БД не могла бы работать. Потому что много таблиц с размером намного больше оперативной памяти.
VD>2. Каждый раз изменять системную информацию.
Это что? Статистику что ли? Так не будет она меняться при каждом изменении.
VD>3. Очень часто делить и объеденять кластры (страницы).
Если сделать кластерный индекс по такому полю, то расщепления страниц могут стать частой операцией. Но это незначительная потеря по сравнению со множеством удобств — для моей базы это так. Да и замедление работы пользователями никак не ощущается.

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

L>Откуда у тебя такие сведения. MS в BOL открытым текстом пишет, что clustered index задает физический порядок записей.
О, даже я напутал, даже страницы физически не упорядочены... Физическое упорядочивание было только в семерке и именно по этому при переходе на 2000 появилась куча проблем, так как народ забивал на order by, уповая на упорядоченность кластерного индекса, особенно этим славились разработчики 1С.
Вообщем вот пример:
Создаем простенькую табличк уи навешиваем на нее кластерный индекс:

create table t (id int not null, fld char(3500) not null)

dbcc traceon(3604)
---------------------------------------------------------------------------
-- вставим в нее 100 записей в порядке убывания id.
declare @i int
set @i = 100
set nocount on
while @i > 0 begin
 insert t values (@i, 'aaa')
 set @i = @i - 1
end

create clustered index ix on t(id)

Смотрим:

declare @db_id int, @tbl_id int 
select @db_id = db_id('Northwind'), @tbl_id = object_id('t') 
dbcc tab(@db_id, @tbl_id)

Да, действительно, все физически упорядочилось как и обещали:

--PageFID PagePID     IAMFID IAMPID      ObjectID    IndexID PageType IndexLevel NextPageFID NextPagePID PrevPageFID PrevPagePID 
--------- ----------- ------ ----------- ----------- ------- -------- ---------- ----------- ----------- ----------- ----------- 
--1       36          NULL   NULL        1109578991  1       10       0          0           0           0           0
--1       344         1      36          1109578991  0       1        0          1           345         1           423
--1       345         1      36          1109578991  0       1        0          1           346         1           344
--1       346         1      36          1109578991  0       1        0          1           347         1           345
-- . . . . . . . . . . 
--1       453         1      36          1109578991  0       1        0          1           454         1           452
--1       454         1      36          1109578991  0       1        0          1           416         1           453

Все страницы с данными (IndexID=0) идут по порядку, так же как и сылаются NextPagePID, PrevPagePID
Ну и внутри страницы:

dbcc page('Northwind', 1, 344, 3)
-- 28e1ce00:  20202020  20202020  20202020  20202020                 
-- 28e1ce10:  20202020    000002                         ...
-- id                               = 1               
-- fld                              = aaa   
-- ...................
-- 28e1dbb7:  20202020  20202020  20202020  20202020                 
-- 28e1dbc7:  20202020    000002                         ...
-- id                               = 2               
-- fld                              = aaa 

А теперь поиздеваемся над табличкой:

delete from t where id between 21 and 70

declare @j int
set @j = 100
set nocount on
while @j < 200 begin
 insert t values (@j, 'bbb')
 set @j = @j + 1
end

И посмотрим что получилось:

declare @db_id int, @tbl_id int 
select @db_id = db_id('Northwind'), @tbl_id = object_id('t') 
dbcc tab(@db_id, @tbl_id)

-- PageFID PagePID     IAMFID IAMPID      ObjectID    IndexID PageType IndexLevel NextPageFID NextPagePID PrevPageFID PrevPagePID 
-- ------- ----------- ------ ----------- ----------- ------- -------- ---------- ----------- ----------- ----------- ----------- 
-- 1       36          NULL   NULL        1109578991  1       10       0          0           0           0           0
-- 1       15          1      36          1109578991  0       1        0          1           25          1           346
-- 1       25          1      36          1109578991  0       1        0          1           28          1           15
-- 1       28          1      36          1109578991  0       1        0          1           29          1           25
-- 1       29          1      36          1109578991  0       1        0          1           30          1           28
-- 1       30          1      36          1109578991  0       1        0          1           31          1           29
-- 1       31          1      36          1109578991  0       1        0          1           33          1           30
-- 1       33          1      36          1109578991  0       1        0          1           34          1           31
-- 1       34          1      36          1109578991  0       1        0          1           347         1           33
-- 1       336         1      36          1109578991  0       1        0          1           337         1           351
-- 1       337         1      36          1109578991  0       1        0          1           338         1           336
-- 1       338         1      36          1109578991  0       1        0          1           339         1           337
-- ...............................................

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

dbcc page('Northwind', 1, 15, 3)

-- 28dd0e00:  20202020  20202020  20202020  20202020                 
-- 28dd0e10:  20202020  01000002  010dbf00    000000     ...........
-- id                               = 100              
-- fld                              = bbb 
-- ..............
-- 28dd1bbf:  20202020  20202020  20202020  20202020                 
-- 28dd1bcf:  20202020    000002                         ...
-- id                               = 101              
-- fld                              = bbb

Там уже записи вовсе не с id = 1, 2...
Итого, при кластерном индексе нет никакой гарантии физического упорядочивания, есть логическое упорядочивание страниц Prev-Next и именно в этом порядке и производится сканирование индекса. И есть гарантия того, что не придется прыгать за следующей записью из середины страницы (пока страница не просмотрена вся — следующая запись гарантировано находится на этой же странице)
Таким образом, хаотичность GUID'ов не может оказывать сколь-нибудь сильного отрицательного эффекта при вставке. Возможно так было в семерке, но 2000 это уже давно не так.

L> Так же, скорее всего передраться могут только пишушие вставляющие транзакции (коих обычно гораздо меньше, чем читающих), а при вставке в середину еще придется драться с читателями.
Опять-таки, при кластеризации по identity записи совершенно разных транзакций попадают в одно и тоже место, и потребоваться эти записи могут так же совершенно разным транзакциям и читать из этой последней страницы будут ни чуть не реже, чем из всех остальных, так что hot spot там может ого-го какой возникнуть. Кластеризация же по неуникальному полю, имеющиму какой-либо смысл с точки зрения бизнес-логики, позволит разнести нагрузку разных транзакций по разным частям таблицы.

L>В твоем пример, кстати, с большой долей вероятности identity в таблице вообще будет не нужен.
А других уникальных идентификаторов там нет, так что либо identity, либо GUID в качестве суррогатного ключа.

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


VD>А что ID-пользователя не может быть идентети? Ты что под этим термином понимаешь?
Вообщем здесь мы рассматривали два довольно слабо связанных вопроса:
1. недостатки guid по сравнению с identity в качестве уникального идентификатора. Одним из недостатков была неоптимальность построения кластерного индекса, отсюда и вылез второй вопрос:
2. Необходимость вообще строить кластерный индекс по PK (не важно identity ПК или guid). Мое скромное мнение заключается в том, что кластерный индекс по PK очень редко бывает оптимальным выбором. В большинстве случаев это лучше чем отсутствие кластерного индекса вообще, но не более того.
И в этом примере совершенно не важео что из себя представляет ID пользователя, главное, что оно не уникально.

VD>ПК первый притендент на кластеризацию. Иначе любая ссылка будет букмарком, коий в скуле очень не хилый.
Это не так. Первый претендент на кластеризацию — это неуникальное поле, которое позволит физически разнести активность разных групп транзакций по разным частям таблицы. ПК по определению уникальный, букмарк за уникальной записью нге бог весть какой накладной расход, а вот когда приходится делать букмарк за группой записей или за диапазоном, то все становится гораздо печальнее.

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

L>ОК, это серьезный аргумент.
Re[11]: Переполнение автоинкрементного поля

Автор: Merle
Дата: 20.07.04

L>Конкретный пример и цифры в студию, pls (если есть). Пока мой здравый смысл утверждает ровно обратное.
Пример с кластерным индексом по userID — из жизни...
При пиковой нагрузке, пока кластерный индекс был по identity производительность была никакой, в профайлере четко было видно очередь из latch'ей на страницу индекса, а агрегатные запросы вообще курили... Периодически лезли дедлоки.
После того, как сделали кластерный индекс по ID пользователя все волшебным образом взлетело, дедлоки исчезли, очередей нет, и заработало все не в пример шустрее.
Собственно решение подсказали и объяснили в чем проблема сами разработчики сиквела, на общественных началах, давно, правда, дело было...
Сейчас, к сожалению, нет возможности эксперименты ставить...

L>С чего бы это? Последняя страница одна, а выборки по чтению идут по всем.
Ну, это действительно скорее проблема интенсивной вставки, но есть такой нюанс, что в реальных очень часто нужны именно последние, только что вставленные данные. И простая вероятность тут мало что решает..

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


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

M>>А читать внимательнее пробовал?
L>Я вроде внимательно читал и тоже не понял.
Это я перенервничал, работать надо, а отвечать интереснее..

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

L>>Да и уникальность у гуидов заканчивается, AFAIR, где-то в райне 2026 года.
M>AFAIK — еще лет на 100 хватит...

где-то сдесь встречал формулировку COMBs.
http://www.informit.com/articles/printerfriendly.asp?p=25862

Типо комбинированный GUID.

Не пробовал, но идея понравилась

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

[]

L>>>См. выше. Производительность с GUID будет хуже, чем int или bigint.
M>>На таблицах с количеством записей порядка нескольких десятков миллионов (на меньших размерах производительность GUID'ов от identity мало отличается) GUID'ы проигрывают identity от 5% до 20%, но во-первых это все равно надо на конкретной задаче мерять, а во вторых такой проигрыш в должной мере компенсируется отсутствием

L>При таких объемах на конкретной задаче это уже поздо будет мерять. Менять структуру уже работающей базы — мало радости. Мне вполне достаточно, что GUID'ы медленнее, чтобы от них отказаться, там где это возможно.

В свое время на БД > 30 гигов получали результат замедления всего лишь чуть больше 3%. На конкретных задачах.

M>> геморроя при различного рода репликациях...

L>А кроме репликаций? В варианте с репликациями я в общем-то ничего против GUID'ов не имею.

Пожалуйста.

Большинство приложений сейчас — это минимум трехзвенка с выделенным сервером приложений. И, естественно, с оторванными курсорами/наборами данных (Я не про веб, где на стороне веб-сервера можно использовать любые курсоры, что, правда, тоже не есть хорошо). А это значит, что при вставке новых данных, с клиента естественно, с использованием identity, или любом другом способе получения ключа в едином центре (в данном случае — в сервере БД), придется "тащить" полученные ключи на клиента. А там их еще и сливать с данными, которые на вставку отправлялись. Или просто, возвращать всю выборку. Что скорости серверу БД тоже не прибавляет.
А при использовании гуидов на клиента ключи возвращать не надо. Их проще на клиенте сгенерить.

Т.е. все сводится опять к тому, о чем ты писал: "Единственное, когда GUID реально бывает нужен — при необходимости распределенной генерации ключей".

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

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


VD>>А что ID-пользователя не может быть идентети? Ты что под этим термином понимаешь?
M>Вообщем здесь мы рассматривали два довольно слабо связанных вопроса:
M>1. недостатки guid по сравнению с identity в качестве уникального идентификатора. Одним из недостатков была неоптимальность построения кластерного индекса, отсюда и вылез второй вопрос:

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

M>2. Необходимость вообще строить кластерный индекс по PK (не важно identity ПК или guid). Мое скромное мнение заключается в том, что кластерный индекс по PK очень редко бывает оптимальным выбором.

И оно снова ошибочное. МС сами советуют это делать. Даже в тестовых БД все ПК у МС кластерные.

M> В большинстве случаев это лучше чем отсутствие кластерного индекса вообще, но не более того.

А еще это лучше чем отсуствие индексов вообще. Так мы далеко в рассуждениях зайдем.

M>И в этом примере совершенно не важео что из себя представляет ID пользователя, главное, что оно не уникально.

Не, ну, доказывая приемущества ГУИДов переходить на другие примеры как не очень верно с точки зрения логики.

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

Откуда дровишки?

M> ПК по определению уникальный, букмарк за уникальной записью нге бог весть какой накладной расход,

Если индекс кластерный, то букмарков не будет вообще, и стало быть не будет и связанных с ними накладных расходов.

M> а вот когда приходится делать букмарк за группой записей или за диапазоном, то все становится гораздо печальнее.

В обещм, тесты в студию!

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

VD>>Если заполнение последовательное, то кластыры набиваются довольно плотно и поиск по ним будет шустрый.
M>Поиск по кластеру более шустрый не из-за плотности заполнения — она всегда одинаковая, а из-за отсутствия bookmark lookups, ввиду того, что, как ты верно заметил, нижние узлы индекса содержат сами данные, ну и из-за относительной физической упорядоченности.

И из-за качества заполнения тоже. При слабом наполнении писк будет медленнее.

VD>>2. Если на таблице есть кластерный индекс, то все ссылающиеся таблицы будут содержать в себе не что иное как значение ключа кластерного индекса.
M>Не таблицы, а другие индексы в этой таблице.

Ну, да. Естественно.

VD>>Без каких либо вероятностей. КИ — это гарантия что твои данные упорядочены физически.
M>Не совсем. Это гарантия того, что физически будут упорядочены страницы, а данные внутри страницы не упорядочены.

Этих подробностей я не знаю. По идеи разумно было бы упорядочивать и внутри страницы.

VD>>3. Последовательное заполнение.
M>Вот последовательное заполнение я бы как раз в минус записал, я уже писал ранее почему.

И зря. Блокировки на сегодня можно ставить и на запись, а вот распыление между разными страницами — это плохо.

VD>>Интересный вывод. С чего бы это?
M>Я имел ввиду данные разных пользователей.

И? Ты уж объясняй подробнее свои идеи.

VD>>С точностью на оборот. Гуид — вот гарантия хаотического разноса данных.
M>Я немного о другом.

А исходный вопрос об этом.

VD>>Вот все это и отнеси к гуидам.
M>Ты меня не понял.

Возможно. Объясни лучше.

VD>>А что ID-пользователя не может быть идентети? Ты что под этим термином понимаешь?
M>ID пользователя может быть любым, здесь я уже о том, что делать кластерный индекс по уникальному идентификатору вообще имеет мало смысла, не важно что это за идентификатор GUID или Identity.

Ну, про недоказанность и маловероятность этой теории я уже вроде говорил...

VD>>Ты вообще-то о гуидах говорил.
M>Да блин, здесь я уже о другом говорю.

А зря. Тема то вон она... в сабже.

VD>>Вот это уже совсем крамола. ПК первый притендент на кластеризацию.
M>Нет. PK — последний кандидат на кластеризацию.

Только по-твоему.
Объясни тогда почеиму когда создаешь ПК на таблице mssql автоматом делает кластерный индекс? Они по твоему вредительством занимаются?
И вообще, можно хоть какие-то доказательства верности твоей теории? Ну, ссылки, результаты тестов...

VD>>Иначе любая ссылка будет букмарком, коий в скуле очень не хилый.
M>Не любая, а очень даже редкая.

Любоая. Если на таблице нет кластеного уникального индекса, то любая ссылка будет букмарком, т.е. все индексы будут содержать букмарки в качестве идентификаторов строк. Если же на таблице есть уникальный кластерный индекс (УКИ), то в индексах будет использоваться именно он (см. BOL).

VD>>Если бы. Его хаотичность — это куда более серьезная проблема.
M>Его хаотичность в большинстве случаев вообще не роляет.

Откуда дровишки? Я говорю о том, что видел сам.

VD>>Кстати, красиво ты опять перешел с ID-пользователя на гуиды. Так в чем кайф гуидов в твоем примере?
M>А читать внимательнее пробовал?

Пробовал. Не помогает. Видимо нужно тщательнее излагать мысли.

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

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

VD>>Все так просто. Сделай эксперемент... Циклик в котором всавляй записи. Сначала с идентити, а потом с гуидами. Думаю, это тебя резко разубедит в своей правоте.

A>Guid долго формируется. Функция NewGuid() шифрует информацию о компьютере где был создан идентификатор, поэтому работает не очень быстро.

Блин, проведи эксперемент. Уверяю тебя скорость генерации гуидов на порядки выше скорости вставки данных в БД.

VD>>1. Поднять практически всю таблицу в память.
A>Если бы это было так, то у меня БД не могла бы работать. Потому что много таблиц с размером намного больше оперативной памяти.

Если памяти нехватает, то всего лишь увеличятся тормоза. Сиквел занимает память пока она есть. Далее если памяти нехватает, он перераспределяет ее для более нужных таблиц. Так что работать то он будет, но медленнее чем мог бы.

VD>>2. Каждый раз изменять системную информацию.
A>Это что? Статистику что ли? Так не будет она меняться при каждом изменении.

Не статистика, а структура индекса.

VD>>3. Очень часто делить и объеденять кластры (страницы).
A>Если сделать кластерный индекс по такому полю, то расщепления страниц могут стать частой операцией. Но это незначительная потеря по сравнению со множеством удобств — для моей базы это так. Да и замедление работы пользователями никак не ощущается.

Это очень значительная потеря. Удобство конечно есть, но долеко не всегда, а в очень определенных случаях. Вот репликация и распределенное формирование идентификаторов как раз тот случай когда можно пожертвовать скорость в угоду удобству. Но делать это без необходимости, по-моему, не стоит.

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

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

VD>>Все так просто. Сделай эксперемент... Циклик в котором всавляй записи. Сначала с идентити, а потом с гуидами. Думаю, это тебя резко разубедит в своей правоте.
M>Делал и не раз и в разных задачах.

Ты не сказки рассказывай, а сделай тест и приведи его код с результатами.

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

Короче: http://www.optim.ru/cs/1999/2/sql7architecture/sql7architecture.asp

Там все описано. Очень помогает.

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

VD>>Ему еще работать нужно.

L> Общая беда.

Но мы с ней боремся!

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

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

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

Ссылки, плиз. Вот перевод МС-ного мануала:
http://www.optim.ru/cs/1999/2/sql7architecture/sql7architecture.asp
А вот цитата из него:

Кластерные индексы

Для каждого кластерного индекса в sysindexes содержится одна строка с indid = 1. При наличии кластерного индекса, страницы в базе данных и строки внутри них размещаются в ключевой последовательности кластерного индекса. Все вставки выполняются по ключевому значению с сохранением последовательности ключей.

В общем, ты путаешь информацию о кластерных индексах с информацией о хранении данных в таблицах не содержащих кластерные индексы. В приципе к теме это не относится, но и тут ты ошибашся.

L>>В описанное верится очень слабо.
M>Тем не менее это так.

Еще раз. Ссылки и тесты в студию.

L>>С некоторой долей вероятности? Это как?
M>Так, что физического упорядочивания записи нет, есть упорядоченность страниц и гарантия того, что запись "меньше" самой "большой" и "больше" самой маленькой записи страницы окажется на этой странице.

См. выше.

L>> И кластерный индекс по identity тут самое то.
M>Нет, не то, другие выборки, как правило, выполняются чаще и более критичны к скорости.

Да лукап по ПК в грамотно спроектированной БД — это самая частая операция. Любая всавка без нее не обходится.

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

BOL от SQL2k: mk:@MSITStore:E:\Program%20Files\Microsoft%20SQL%20Server\80\Tools\Books\createdb.chm:/cm_8_des_05_5h6b.htm

A clustered index determines the physical order of data in a table. A clustered index is analogous to a telephone directory, which arranges data by last name. Because the clustered index dictates the physical storage order of the data in the table, a table can contain only one clustered index. However, the index can comprise multiple columns (a composite index), like the way a telephone directory is organized by last name and first name.

Что уж МС называет физическим порядком решать тебе. Видимо они специально врут. Но как минимум записи в странице точно упорядочены. Или это уже не индекс.

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

А вот собственно цитата от туда же:

Clustered indexes are also efficient for finding a specific row when the indexed value is unique. For example, the fastest way to find a particular employee using the unique employee ID column emp_id is to create a clustered index or PRIMARY KEY constraint on the emp_id column.

Note PRIMARY KEY constraints create clustered indexes automatically if no clustered index already exists on the table and a nonclustered index is not specified when you create the PRIMARY KEY constraint.

по-моему, совершенно однозначно дают понять...

ЗЫ

Еще раз говорю. Создай две одинаковые талички. Одну с гуидом и некластерным индексом. Другую с интом и кластерным. Потом пару тройку вторичных индексов и связей на них (на другие табличи). Ну, и далее все будет ясно.

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

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

L>>Откуда у тебя такие сведения. MS в BOL открытым текстом пишет, что clustered index задает физический порядок записей.
M>О, даже я напутал, даже страницы физически не упорядочены... Физическое упорядочивание было только в семерке и именно по этому при переходе на 2000 появилась куча проблем, так как народ забивал на order by, уповая на упорядоченность кластерного индекса, особенно этим славились разработчики 1С.
M>Вообщем вот пример:

Очень интересный результат. Статейку не хочешь на эту тему написать?

M>Таким образом, хаотичность GUID'ов не может оказывать сколь-нибудь сильного отрицательного эффекта при вставке. Возможно так было в семерке, но 2000 это уже давно не так.

С этим все равно не согласен. Аргументы все те же — фрагментация индекса, меньшая плотность заполнения и cache misses.

L>> Так же, скорее всего передраться могут только пишушие вставляющие транзакции (коих обычно гораздо меньше, чем читающих), а при вставке в середину еще придется драться с читателями.
M>Опять-таки, при кластеризации по identity записи совершенно разных транзакций попадают в одно и тоже место, и потребоваться эти записи могут так же совершенно разным транзакциям и читать из этой последней страницы будут ни чуть не реже, чем из всех остальных, так что hot spot там может ого-го какой возникнуть.

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

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

Кластеризации по неуникальному полю вообще не бывает. Сервер все равно сделает кластерный индекс уникальным. Вот ты все про бизнес логику. А с чего ты решал, что бизнес-логике нужны именно такие запросы. Да, такие запросы бывают, но в тех базах, с которыми я работал, они составляли от силы процентов 30. И грузили они сервер не очень сильно. А основная нагрузка шла на join'ы, которые как раз и делаются по identity и напрямую выигрывают от его кластеризации.

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

Т.е. композитный уникальный ключ приемлемой длины в данном случае не построишь?

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

L>>С чего это она одинакова? При вставке в произвольнные места будет происходить дробление страниц, а это как раз понижение плотности.
M>Страница делится напополам (или на две трети, уже не помню) часть данных

В 7-ке напополам:
When this occurs, SQL Server needs to divide up the data on the full page and move about half of the data to a new page so that both pages now have some open space.

M> переносится на новую страницу, таким образом после разбиения образуются две страницы заполненные примерно одинаково... Следующее разбиение будет тогда, когда страница опять заполнится до конца, и опять поровну. Если считать, что guid
M> хаотический, то все страницы заполняются доконца равномерно. identity всегда

Равномерно — да, но заполненность у них при этом может получиться хреновой.

M> пишет в последнюю страницу, после того как та окажется заполненой она делится пополам и часть данных переносится на следующую страницу, которая продолжает заполняться... То есть, при identity все страницы кроме последней заполнены

В случае с хаотической вставкой — так и будет. В случае с последовательной, думаю, ты заблуждаешься. Вот выдержка из MSDN'овской статьи (еще по 7-ке):
Page splitting occurs when an index page or data page can no longer hold any new rows and a row needs to be inserted into the page because of the logical ordering of data defined in that page.
Обрати внимание на выделенное. В случае вставки в конец нет никакой необходимости дробить страницу — гораздо проще начать новую.

M> наполовину, а при guid'ах, скорее всего, окажется что страницы заполнены больше чем на половину, но всего страниц занято меньше, хотя распределение может оказаться и не столь равномерным.

Наполовину — это очень плохо для крупных баз. Нормальные филфакторы — 70-80%, если планируются довольно частые вставки. Иначе можно и больше.

M>Но количество расщеплений индекса будет в среднем одинаковым в обоих случаях.

Нет.

M>>>А читать внимательнее пробовал?
L>>Я вроде внимательно читал и тоже не понял.
M>Это я перенервничал, работать надо, а отвечать интереснее..

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

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

L>>С чего бы это? Последняя страница одна, а выборки по чтению идут по всем. Вероятность того, что понадобиться именно последняя страница порядка 1/N (N-число страниц). При больших N она ничтожна.

A>Если в таблицу идут частые инсерты, то, при кластерном индексе по identity, вероятность того что потребуется последняя страница пропорциональна количеству вставляемых в секунду записей и обратно пропорциональна среднему размеру записи. И эта вероятность никак не зависит от числа страниц.

Чушь. Большиству читающих транзакций новые записи вообще не нужны (о их существовании еще просто никто не знает).