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

VD>Ничего такого втом что ты привел нет. По крайней мере твои выводы точно с этих данных делать нельзя.
Почему нельзя?

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

VD>1. Где подтерждение этому? Опровержение вроде постоянно появляются. Да и логике это противоречит. Индекс есть индекст. Его записи обязаны быть упорядочены.
Они логически упорядочены, ссылками друг на друга, а физически лишь от части, есть гарантия, что диапазон окажется на одной странице, но внутри страницы они все равно в перемешку.

VD>2. Какя разница как физически что-то реализовано?
Для вставки большая, данные можно пихать в любое свободное место на странице, пока оно есть.

VD>Не делать сотрировки при чтении.
А они и не делаются.

VD> Это между прочем не быстрая операция. Вот какой смысл хранить данные неупорядоченно в индеске? Это действительно маразм.
Это не маразм, а оптимизация вставки.

VD> Как минимум нужно хотя бы сделать микро-индес внутри страницы.
Вот это действительно маразм...

VD>Я вот видил вставку из одноко потока. И разница была очень явная.
Да никого не интересует вставка из одного потока, я для таких задач какой-нибудь MySQL возьму или FB embedded, они и сиквел и Оракл и DB2 порвут, всех вместе на таких задачах. Реально то с базой работает много потоков и каждому свое надо.

VD>Ну, и что ты доказываешь?
Что гуиды ничем не хуже identity.

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

VD>А сколько ФК можно кластеризовать на одной таблице? И как будет делаться поиск строки на втором и третьем ФК?
А это уже надо по задаче смотреть, какой кластерным, а какой не очень. В крайнем случае сделать так, чтобы на одну таблицу больше одного FK не приходилось.

VD>В общем, еще раз. Тесты в студию.
Да какие тесты? Реальные приложения поднимать и нагрузку эмулировать у меня времени нет. То что выбор по диапазонам с помощю кластерного оптимальнее — ты и сам знаешь. По моему опыту диапазонных запросов — большинство и оптимизировать их не в пример сложнее, чем выборку по PK...

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

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

VD>>А сколько ФК можно кластеризовать на одной таблице? И как будет делаться поиск строки на втором и третьем ФК?
M>А это уже надо по задаче смотреть, какой кластерным, а какой не очень. В крайнем случае сделать так, чтобы на одну таблицу больше одного FK не приходилось.

Мне кажется ты тут общими фразами не отделаешься, нужно разжёвывать, или ты просто хотел растянуть удовольствие?

В общем, ни хрена в MS-SQL не смыслю но скажу из общетехнических соображений, про джойны:

Предположим, что имеется табличка tab1 с полями pk1 ( identyty ) и selection1 ( некое поле по которому идет выбор) и прочие , а также дочерняя табличка tab2 с полями pk2 ( identity), fk2_pk1 ( внешний ключь на tab1.pk1) и прочими.

Ну и далее предположим, мы выполняем запрос с соединением этих табличек

select <...samefields from tab1 and tab2...>  
from tab1, tab2 where tab1.selection1 = :same_value and tab1.pk1 = tab2.fk2_pk1

Предположим, что под условие tab1.selection1 = :same_value подподают 100 записей tab1,
по внешнему ключу к каждой записи tab1 присоединяется 10 записей из tab2,
по полям pk1, selection1, pk2, fk2_pk1 имеются индексы глубина всех индексов 3.
Пусть таблички большие по сравнению с объемом выборки и оптимизатор решает выбрать nested loops для их соеденения.


1) Рассмотрим сначала вариант когда обе таблички имеют кластерный индекс по первичному ключу.
Для выбора данных по selection1 ( будем считать что оптимизатор выбрал index range scan) потребуется чтение 3 страниц индекса по полю selection1, и скорее всего в листевом блоке найдем все 100 ссылок на строки содержащие
selection1 = :same_value. Поскольку кластеризация у нас по pk1, то соответственно по selection1 её быть не может, таким образом следует ожидать что все 100 искомых значений находятся на 100 РАЗНЫХ страницах таблицы, и соответственно что бы к ним обратится надо осуществить ещё 100 чтений страниц.
Далее для каждой выбранной строки tab1 надо найти дочерние в tab2. Для этого у нас есть индекс по fk2_pk1
т.е по каждому найденноq в tab1 строке необходимо выполнить по 3 чтения страницы индекса по fk2_pk1, где в листьевой странице мы найдем искомые 10 ссылок, поскольку индекс по fk2_pk не кластерный следует ожидать, что для получения соответствующих строк таблицы придется обратится к 10 разным страницам.

Итого для этого варианта имеем 3 + 100 + (3 + 10) * 100 = 1403 чтения страниц.

2) Пусть у нас кластерные индексы теперь не по PK, а по полям tab1.selection1 и tab2.fk2_pk1.
Для выбора данных по selection1 потребуется чтение 3 страниц индекса по полю selection1, там же мы находим все
100 искомых строк, ну пусть они не влезли на одну страницу и нам понадобилась еще 1 страница.
Далее для каждой выбранной строки tab1 надо найти дочерние в tab2. Для этого у нас есть кластерный индекс по fk2_pk1 т.е по каждому найденноq в tab1 строке необходимо выполнить по 3 чтения страницы индекса по fk2_pk1
и в листьевой вершине мы найдем все 10 искомых значений.

Итого для соединения нам понадобится ( 3 + 1) + (3)*100 = 304 чтения страниц.

По объему логического чтения вариант когда кластерный индекс делается не по PK оказался в 4,5 раза эффективнее, в данном примере.

VD>>А сколько ФК можно кластеризовать на одной таблице? И как будет делаться поиск строки на втором и третьем ФК?
Смотрим:
3) (вариант 2, но кластерный индекс по другому FK) Пусть у нас теперь нет кластерного индекса по FK2_PK1, а есть по некому другому FK.
Выборка из первой таблицы таже, и для каждой строки из tab2 потребуется выполнить по 3 чтения страницы индекса по fk2_pk1 и сбегать к 10 блокам по 10 ссылкам.

Итого:
3+100 + (3 + 10) * 100 = 1403
То же значение, что и при кластеризации по PK2, что и следовало ожидать если кластеризация идет не потому индексу что используется, то совершенно пофиг по какому индексу она сделана ( PK или другому FK), на рассматриваемую операцию это не влияет.



В итоге
1) при применение кластерных индексов по PK проигрышь по предпологаемому объему логического i/o в примере c соединением составил 4,5 раза. При увеличении количества "дочерних" записей он будет возрастать.
2) При отсутствии кластерного индекса по FK участвуещему в соединении разницы между вариантом соединения где кластеризация идет по PK ( вариант 1 ) и по другому полю ( вариант 3) не ожидается.

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

KA>Мне кажется ты тут общими фразами не отделаешься, нужно разжёвывать, или ты просто хотел растянуть удовольствие?
Да какое тут удовольствие..

KA>В общем, ни хрена в MS-SQL не смыслю но скажу из общетехнических соображений, про джойны:
В Оракле, если я правильно помню, IOT (что есть аналог кластерного индекса в MSSQL) тоже не по PK рекомендуют делать, примерно из тех же соображений.

KA>3) (вариант 2, но кластерный индекс по другому FK) Пусть у нас теперь нет кластерного индекса по FK2_PK1, а есть по некому другому FK.
KA>Выборка из первой таблицы таже, и для каждой строки из tab2 потребуется выполнить по 3 чтения страницы индекса по fk2_pk1 и сбегать к 10 блокам по 10 ссылкам.
KA>Итого:
KA>3+100 + (3 + 10) * 100 = 1403
Если в первой (master) табличке кластеризация по selection1 то понадобится не 3+100, а 3+1 чтений (если у нас 3й вариант такой же как второй, а не как первый ). Тогда общая стоимость будет 3+1 + (3 + 10) * 100 = 1304 — все хлеб.

Плюс, не следует забывать, что чтение диапазонов с использованием кластерного индекса более эффективно ввиду использования "Read Ahead". То есть, грубо говоря, при удачном стечении обстоятельств 403 чтения второго варианта выполнятся оптимальнее, чем просто 403 букмарк лукапа.

KA>В итоге
KA>1) при применение кластерных индексов по PK проигрышь по предпологаемому объему логического i/o в примере c соединением составил 4,5 раза. При увеличении количества "дочерних" записей он будет возрастать.
KA>2) При отсутствии кластерного индекса по FK участвуещему в соединении разницы между вариантом соединения где кластеризация идет по PK ( вариант 1 ) и по другому полю ( вариант 3) не ожидается.
Спасибо, прмерно это я и имел ввиду, просто с Владом спорить бывает очень утомительно, да и на работе завал...

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

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


KA>>В общем, ни хрена в MS-SQL не смыслю но скажу из общетехнических соображений, про джойны:
M>В Оракле, если я правильно помню, IOT (что есть аналог кластерного индекса в MSSQL) тоже не по PK рекомендуют делать, примерно из тех же соображений.
К сожелению это не так, кроме как по PK нельзя сделать
Oracle® Database Concepts 10g Release 1 (10.1) Part Number B10743-01 Overview of Index-Organized Tables:

An index-organized table has a storage organization that is a variant of a primary B-tree. Unlike an ordinary (heap-organized) table whose data is stored as an unordered collection (heap), data for an index-organized table is stored in a B-tree index structure in a primary key sorted manner. Besides storing the primary key column values of an index-organized table row, each index entry in the B-tree stores the nonkey column values as well.

Отсюда приминимость IOT в Oracle, на мой взгляд, достаточно мала.

KA>>3) (вариант 2, но кластерный индекс по другому FK) Пусть у нас теперь нет кластерного индекса по FK2_PK1, а есть по некому другому FK.
KA>>Выборка из первой таблицы таже, и для каждой строки из tab2 потребуется выполнить по 3 чтения страницы индекса по fk2_pk1 и сбегать к 10 блокам по 10 ссылкам.
KA>>Итого:
KA>>3+100 + (3 + 10) * 100 = 1403
M>Если в первой (master) табличке кластеризация по selection1 то понадобится не 3+100, а 3+1 чтений (если у нас 3й вариант такой же как второй, а не как первый ). Тогда общая стоимость будет 3+1 + (3 + 10) * 100 = 1304 — все хлеб.

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

P.S. Чего то коды форматирования внизу страницы не срабатывают, приходится вводить руками, это только у меня так или что то "улучшили"?

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

D>>Предположим так. Какого по твоему мнению будет размер такоего составного ключа?
M>Не на много больше чем обычного.

Не на много это в два раза, если ключ целочисленный.

VD>>И насколько он окажется эффекнивнее при лукапе чем кластерный индекс по уникальному поли целого типа?
M>При лукапе чего?

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

M> Тут все от запросов зависит.

Ничего тут ни от чего не зависит. Уникальный целочисленный ключ будет иметь развем 4 байта. Навигация по нему (на 32-битных платформах) будет всегда быстрее чем по любому другому, а его размер меньше (а стало быть и размер всех остальных индексов).

VD>>Блин. Да раз в год по праздникам может оказаться нужно последовательно сканировать таблицу.
M>Ха, раз в год. сканировать куски таблицы и выбирать диапазоны приходится гораздо чаще и запросы эти самые критичные.

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

VD>> А джоины делать нужно постоянно.
M>Джойны тоже разные бывают и в большинстве случаев это все тоже сканирование диапазона.

Нет. Джоины в большинстве случаев — это лукап по ПК (если конечно БД спроектирована нормально). Причем вариантов джоинов обычно много, и на все ФК кластерных индексов не сделаешь. Так что как раз КИ на ПК — это отличное решение по умолчанию. Вот если есть явный перекос в сторону одного из видов запросов, то можно подумать инад изменением схемы.

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

VD>Не на много это в два раза, если ключ целочисленный.
Это "в два раза" все равно не много.

VD>Записи, записи. Напомню, что по кластерному индексу производится выборка при навигации по любому индексу, так как в некластерных хранится именно ключ кластерного.
Не навигация по кластерному индексу, а ссылка на запись представляет из себя ключ кластерного индекса.

VD>Ничего тут ни от чего не зависит.
Зависит.

VD> Уникальный целочисленный ключ будет иметь развем 4 байта. Навигация по нему (на 32-битных платформах) будет всегда быстрее чем по любому другому, а его размер меньше (а стало быть и размер всех остальных индексов).
Размер ключа для 32 битной платформы, вообще роли не играет, так как эти потери, попросту другой порядок малости по сравнению с дисковыми операциями. Все упирается в них. Для дисковых операций разница размера ключа в несколько байт практически ничего не значит. Заметный проигрыш можно получить при разнице в размерах ключа в сотню байт и размерах таблиц в миллионы и десятки миллионов записей.

VD>Ты все таблицы тлько одним способом выбираешь? Нет? Ну, тогда должен понимать, что сделав кластерный индекс по левому полю ты получишь ускорение при выборке по ниму, и замедлишь все остальные выборки.
Оно не левое. Это PK левый.

VD> Бесспорно иногда это оправданно. Но возводить это в ранг правила в корне не верно.
Я в ранг правила возвожу другое: "если на таблице помимо PK есть другие индексы, то вероятнее всего эти другие индексы стоит сделать кластерными, а не PK"

VD>Нет. Джоины в большинстве случаев — это лукап по ПК (если конечно БД спроектирована нормально).
Покажи мне такой джойн. Или у меня все базы не правильные?
Еще раз: ПК — уникальный, лукап за одной записью ничего не стоит. Выборка по некластерному диапазону означает лукап за всеми записями этого диапазона, а это уже дорогая операция. Для примера, если у нас в запросе в диапазон попадает 5 записей — это означает 5 полноценных букмарк-лукапов (поскольку с хорошей вероятностью все пять записей сидят на разных страницах), а значит диапазонный запрос оказался в пять раз дороже. Таким образом, если выборка по ПК более чем в пять раз чаще, чем выборка по диапазону, фиг с ним, пусть будет кластерным, но в реальных задачах обычно бывает наоборот, и в диапазон попадает не пять записей, а гораздо больше.
Поэтому я и говорю (и не только я, как выяснилось), что ПК один из наименее вероятных кандидатов на кластеризацию.
Плюс к этому, правильно выбранный кластерный индекс позволяет размазать нагрузку по таблице и физически разнести разные транзакции от греха подальше.

VD> Причем вариантов джоинов обычно много, и на все ФК кластерных индексов не сделаешь.
На все и не надо, надо на один, самый критичный.

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

KA>Отсюда приминимость IOT в Oracle, на мой взгляд, достаточно мала.
Упс, странно... А причины такого ограничения известны? И что, в Оракле PK — особенный? Или тут имелась ввиду уникальность? тогда ничего страшного...

KA>P.S. Чего то коды форматирования внизу страницы не срабатывают, приходится вводить руками, это только у меня так или что то "улучшили"?
Да вроде все работает, но я в последнее время больше янусом...

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

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

VD>>А сколько ФК можно кластеризовать на одной таблице? И как будет делаться поиск строки на втором и третьем ФК?
M>А это уже надо по задаче смотреть, какой кластерным, а какой не очень. В крайнем случае сделать так, чтобы на одну таблицу больше одного FK не приходилось.

Сдается мне, что фантазировать нужно меньше. Количество ФК определяется потребностями дизайна. Из-за смутных предпочтений АБД вряд ли кто станет менять дизайн БД.

А насчет того, что на задачу нужно смотреть тебе сразу сказали. Это ж ты даешь универсальный совет "Гуиды на ПК, и ни в коем случае не делать ПК кластерным...".

VD>>В общем, еще раз. Тесты в студию.
M>Да какие тесты?

Очень просты. ПК в иде ГУИД-а и без кластра вс. Инт + КИ. Плюс табличек 5 связанных между собой и набор запросов по ним. Естественно хотя бы в одной табличне нужно залить пару миллионов данных (чтобы хоть было видно не вооруженным взглядом).

M> Реальные приложения поднимать и нагрузку эмулировать у меня времени нет.

Там и без нагрузки будет все отчетливо вдино. Даже одиночный запрос будет отличаться.

M> То что выбор по диапазонам с помощю кластерного оптимальнее — ты и сам знаешь.

Ну, вот и покажешь как это будет выглядеть при реальных джоинах.

M> По моему опыту диапазонных запросов — большинство и оптимизировать их не в пример сложнее, чем выборку по PK...

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

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

KA>Мне кажется ты тут общими фразами не отделаешься, нужно разжёвывать, или ты просто хотел растянуть удовольствие?

KA>В общем, ни хрена в MS-SQL не смыслю но скажу из общетехнических соображений,

Хорошая аргументация. Сам я подсудимого не знал, но как и весь Советский наро...

Матиматика тоже забавная. Правда не учитывает кое чего и кое в чем основывается на недоказанных предположениях, но выглядит внушитешьно. Остается только доказать состоятельность всех рассчетов. Сделай таблички и померяй скорость. Причем таблички сделай не две, а хотя бы пять и джоинов не один, а тоже пять или десять. Померяй скорость и потом расскажи свои ощущения.

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

M>Спасибо, прмерно это я и имел ввиду, просто с Владом спорить бывает очень утомительно, да и на работе завал...

С владом не нжуно спорить. Ему нужно предъявлять разумные не противоречивые аргументы и факты. В данном случае аргументы не убедительны. Самое убедительное — это банальный тест. Хочешь убедить сделай его и вопрос отпадет. А до тех пор я лично вижу кучу ошибок в логических рассуждениях.

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

VD>> Как минимум нужно хотя бы сделать микро-индес внутри страницы.
M>Вот это действительно маразм...

Маразм... Нда. Веский аргумент ничего не скажешь. Значит по твоему тупой перебор быстрее будет?

VD>>Я вот видил вставку из одноко потока. И разница была очень явная.
M>Да никого не интересует вставка из одного потока, я для таких задач какой-нибудь MySQL возьму или FB embedded, они и сиквел и Оракл и DB2 порвут, всех вместе на таких задачах. Реально то с базой работает много потоков и каждому свое надо.

В большинстве OLTP-систем вставка не такое уж частое действие. И конкурентная вставка может вообще быть рдкостью, а вот выборка идет постоянно. И ее в разы больше. Бывают конечно исключения, но они все же не так часты.

VD>>Ну, и что ты доказываешь?
M>Что гуиды ничем не хуже identity.

Вот только в твоих словах все меньше и меньше о ГУИД-ах. И все больше и больше ухода от темы.

Открой любой TPC-C тест и погляди какие там типы данных используются. Если хоть один ГУИД найдешь можно будет дальше обсудить эту теорию, а так в эту сказку я без тестов не поверю.

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

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

VD>>Никаких существенных изменений с тех времен не было.
M>Ну так, Storage Engine периписали,

Ничего там серьезно не переписывали.

M> оптимизатор переписали,

Он тут вообще никакой роли не играет.

M> а больше действительно, особо серьезных изменений не было..

Текст который я привел до сих пор лежит в BOL.

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

А какая разница физически не физически? Факт в том, что кластерный индекс намного экономичнее обычного (хотя бы потому, что обычный один фиг будет еще и кластерным пользоваться). И факт в том, что кластерный индекс должен быть на тех полях по которым чаще всего делается выборка. А это с обычно и есть ПК. Для некоторых таблиц это не так вот на них можно и заняться оптимизацией. В остальных же ПК — это лучший выбор. Иначе ты ускоришь один запрос, а все остальные замедлишь. Гуидя же — это вообще никому ненужный удар по производительности. Применять их в обычных случях можно только от большой к ним любьви. Вот если нужна репликация или это резко упрощает реализацию какого-нить сервера приложений с O/R-мапингом, то другое дело. Но нужно понимать, что за это платишь решьной производительностью и объемами данных. Любой индекс при этом увеличится минимум в четверо. Нафиг оно надо?

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

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

VD>> Но если таблица постоянно идет через джоин, то как раз ПК самый лучший выбор.
M>Джоин чего? джойны тоже разные бывают, и как правило джойнится все тот же диапазон.

Джоины в большинстве случаев идут с ПК на ФК. Криворуких программистов и АБД в рассчет не берем. Причем ПК то на таблице будет один, а вот ФК будет скоре всего куча. И если это так, и нет явного перекоса в сторону выборки по одному ФК, то смысла делать кластерный индекс на этом ФК нет. А вот КИ на ПК при этом даст повышение производительности, так как лукап по ПК будет наиболее шустрым, ПК, а стало быь и ссылки на записи в обычных индексах будут иметь минимальный размер (и будут совпадать со словом процессора). Стало быть вся система станет быстрее. Собственно потому МС и делает по умолчанию на ПК КИ.

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

Блин. И что даст ускорение выборки по одному ФК если таблица постоянно лукапится по ПК и на нае есть еще с десяток ФК? Да, один запрос сужественно ускоряется. А 100 других замедляется.

Представь себе справочник в тотором, ну, 1000-3000 записей. Его прямая выборка с сотрировкой не представляет никаих проблем. Даже отсуствие индекса по текстовому полю не проблема, ведь сортировка таких объемов не проблема. Но справочник очень часто используется по ссылке в других таблицах. При этом справочник постоянно участвует в джоинах. Причем так как объемы в нем никакие, то сервер постоянно лупапит по его ПК. Далее мы следуя твоему мудрому совету делаем КИ по текстовому полю аргументируя это тем, что мол это даст нам невероятное увеличение скорости фильтрации справочника. А на деле мы получаем огромные объемы скана по НКИ с лукапом по текстовому полю. В итоге мелкая табличка становится причиной снижения общего быстродействия системы на несколько процентов. И все почему? А потому что мы следуем идеи панацеизма. Далее мы следуя другому мудрому совету меняем целочисленный ID на гуид и получаем четырехкратное увеличение объема индеков (ФК-шных) во всех таблицах ссылающийся на наш справочник плюс увеличение индексов самой таблицы, да и размера самой таблицы (хотя по стравнению с огромными ссылающимися таблицами это уже все фигня). Итоно получаем нехилый удар по производительности. Уря товарищи! За то мы выполнили все мудрые советы!

Да бесспорно, что в некоторых случаях и КИ может быть выгодно сделать на ФК. Например, таблицы в которых хранятся нижнии уровни иерархий вроде таблиц товаров очень даже могут выиграть от этого, так как в них большой процент выборки делается именно по ФК, а доступ по ПК обычно ведется по одной записи. Но таких таблиц 2-3, ну 5. А правило то мы предлагаем как универсальное.

M>Ну надыбай.

Из БОЛ я тебе уже приводил.

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

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

ЗЫ

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

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

Кстати, приведи год выпуска книг и версии серверов о которых идет речь. А то не ясно о каких хотспотах идет речь применительно к sql2k где есть блокировка на строку, да и в семерке где есть блокировка на строку при вставке.

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

L>>>>В описанное верится очень слабо.
M>>>Тем не менее это так.
L>>Конкретный пример и цифры в студию, pls (если есть). Пока мой здравый смысл утверждает ровно обратное.
M>Вот цитаты из умных книжек:
M>Ken Henderson, "Guru's Guide To T-SQL":

Наверное ты меня убедил.

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

Что-то закрались у меня сегодня сомнения насчет чистоты выводов этого эксперимента.

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

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

M>Смотрим первую страницу:

Судя по prevPageID = 346, это не первая страница.

M>

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

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

M>Там уже записи вовсе не с id = 1, 2...

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

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


VD>Джоины в большинстве случаев идут с ПК на ФК.
Правильно.

VD> Причем ПК то на таблице будет один, а вот ФК будет скоре всего куча.
Правильно.

VD>И если это так, и нет явного перекоса в сторону выборки по одному ФК,
Что значит перекос в сторону выборки по одному ФК?

VD> то смысла делать кластерный индекс на этом ФК нет.
Как раз в этом случае смысл есть.

VD> А вот КИ на ПК при этом даст повышение производительности, так как лукап по ПК будет наиболее шустрым, ПК, а стало быь и ссылки на записи в обычных индексах будут иметь минимальный размер (и будут совпадать со словом процессора). Стало быть вся система станет быстрее.
Все не так. ПК — один, один раз сходить за записью — не проблема, FK много, много раз ходить за записью накладно, поэтому имеет смысл делать кластерным FK.

VD>Собственно потому МС и делает по умолчанию на ПК КИ.
MS делает ПК кластерным вовсе не по этому, я уже писал почему, и не только я.

VD>Блин. И что даст ускорение выборки по одному ФК если таблица постоянно лукапится по ПК и на нае есть еще с десяток ФК?
Ты чего-то путаешь. Таблица по ПК не постоянно не ищется. И при чем здесь ФК на таблицу? Если есть ФК у таблицы то он, скорее всего один.

VD>Да, один запрос сужественно ускоряется. А 100 других замедляется.
Никто не замедлится.

VD>Представь себе справочник в тотором, ну, 1000-3000 записей.
Эээээ... Справочник — это особый случай, ты же не будешь утверждать, что правильная база вся состоит из справочников? Скорее наоборот. Справочники — это скорее исключение.
Больше как раз запросов таких, как привел KisA: Re[16]: GUID и кластерны

Автор: KisA
Дата: 22.07.04

VD> Итоно получаем нехилый удар по производительности. Уря товарищи! За то мы выполнили все мудрые советы!
Ну не надо передергивать, я нигде не говорил, что всегда надо использовать не ПК? Я говорил, что ПК наименее вероятный кандидат.

VD>Из БОЛ я тебе уже приводил.
В БОЛ из пяти или шести примеров ПК только один.

VD>Но все же кандидат?
Я где-то утверждал обратное?

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

VD> А без него скорость работы будет принципиально хуже.
Совершенно верно.

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

VD>Именно ПК первый претендент,
Последний. Ну предпоследний, за вычетом текстовых и длинных варчарных полей.

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

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

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

VD>Кстати, приведи год выпуска книг и версии серверов о которых идет речь. А то не ясно о каких хотспотах идет речь применительно к sql2k где есть блокировка на строку, да и в семерке где есть блокировка на строку при вставке.
Во всех цитатах, за исключением одной речь идет о 2k, в одной о 7.
Года выпуска с 2000 по 2003, где 7 там не знаю, отдельная глава про индексы взятая с сайта MS.