Есть совет для SQL Server 2000:
"Создание максимально коротких кластерных индексов позволяет уменьшить размер некластерных индексов, поскольку теперь они ссылаются на кластерный индекс (если такой существует), а не на прямую на таблицу."
Устройство индексов как кластерных. так и некластерных на уровне страниц приблизительно знаю. Однако вникнуть в суть совета и почему так не могу. Не могли бы вы разъяснить.

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

E>Есть совет для SQL Server 2000:
E>"Создание максимально коротких кластерных индексов позволяет уменьшить размер некластерных индексов, поскольку теперь они ссылаются на кластерный индекс (если такой существует), а не на прямую на таблицу."
E>Устройство индексов как кластерных. так и некластерных на уровне страниц приблизительно знаю. Однако вникнуть в суть совета и почему так не могу. Не могли бы вы разъяснить.

Некластерный индекс хранит на своих страницах ссылки на кластерный индекс (типа foreign key). Чем короче кластерный индекс, тем меньше размер ссылки и тем больше индексов поместиться на каждой странице.

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

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

E>>Есть совет для SQL Server 2000:
E>>"Создание максимально коротких кластерных индексов позволяет уменьшить размер некластерных индексов, поскольку теперь они ссылаются на кластерный индекс (если такой существует), а не на прямую на таблицу."
E>>Устройство индексов как кластерных. так и некластерных на уровне страниц приблизительно знаю. Однако вникнуть в суть совета и почему так не могу. Не могли бы вы разъяснить.

S>Некластерный индекс хранит на своих страницах ссылки на кластерный индекс (типа foreign key). Чем короче кластерный индекс, тем меньше размер ссылки и тем больше индексов поместиться на каждой странице.
Что значит "короче" приминительно к кластерному индексу?

sunsquirel пишет:

> Некластерный индекс хранит на своих страницах ссылки на кластерный
> индекс (типа foreign key). Чем короче кластерный индекс, тем меньше
> размер ссылки и тем больше индексов поместиться на каждой странице.

Можно я поясню ?

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

Теперь понятно, почему кластерный должен быть как можно меньше ?
И, кстати, лучше ещё и уникальный чтобы был.

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

MZ>Можно я поясню ?

MZ>Ссылка на кластерный индекс -- это значения всех полей кластерного
MZ>индекса. Именно они храняться в листовых страницах некластерного
MZ>индекса. Сделано это для того, чтобы не нужно было maintain-ить
MZ>некластерные индексы при изменении кластерного/таблицы.

MZ>Теперь понятно, почему кластерный должен быть как можно меньше ?
MZ>И, кстати, лучше ещё и уникальный чтобы был.

Спасибо! У меня не было времени так подробно это расписывать

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

E>>>Устройство индексов как кластерных. так и некластерных на уровне страниц приблизительно знаю. Однако вникнуть в суть совета и почему так не могу. Не могли бы вы разъяснить.
S>>Некластерный индекс хранит на своих страницах ссылки на кластерный индекс (типа foreign key). Чем короче кластерный индекс, тем меньше размер ссылки и тем больше индексов поместиться на каждой странице.
E>Что значит "короче" приминительно к кластерному индексу?

короче = занимает меньше байт. int будет короче bigint и тем более uniqueidentifier.

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

S>Некластерный индекс хранит на своих страницах ссылки на кластерный индекс (типа foreign key). Чем короче кластерный индекс, тем меньше размер ссылки и тем больше индексов поместиться на каждой странице.

По-моему кто-то путает термины "кластерный индекс" и "первичный ключ".

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

MZ>Ссылка на кластерный индекс -- это значения всех полей кластерного
MZ>индекса. Именно они храняться в листовых страницах некластерного
MZ>индекса. Сделано это для того, чтобы не нужно было maintain-ить
MZ>некластерные индексы при изменении кластерного/таблицы.

MZ>Теперь понятно, почему кластерный должен быть как можно меньше ?
MZ>И, кстати, лучше ещё и уникальный чтобы был.

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

_d_m_ пишет:

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

Вот именно, и увеличивается ещё его длина. Поэтому я и сказал -- лучше
уникальный.

wildwind пишет:

> По-моему кто-то путает термины "кластерный индекс" и "первичный ключ".

Нет, никто ничего не путает. Первичный ключ тут вообще ни при чём.
Это ты путаешь, потому что обычно на MSSQL первичный ключ и делают
кластерным индексом, потому что PK в БД обычно никогда не изменяется.

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

MZ>wildwind пишет:

>> По-моему кто-то путает термины "кластерный индекс" и "первичный ключ".

MZ>Нет, никто ничего не путает. Первичный ключ тут вообще ни при чём.
MZ>Это ты путаешь, потому что обычно на MSSQL первичный ключ и делают
MZ>кластерным индексом, потому что PK в БД обычно никогда не изменяется.

Да, верно. На самом деле я подразумевал "ключ кластерного индекса". Именно он может быть короче/длиннее в данном контексте, а не индекс как объект БД.

Considerations

It is important to define the clustered index key with as few columns as possible. If a large clustered index key is defined, any nonclustered indexes that are defined on the same table will be significantly larger because the nonclustered index entries contain the clustering key.
...

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

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

MZ>И, кстати, лучше ещё и уникальный чтобы был.
Это сделает кластерный индекс практически бесполезным для основной области его применения.

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

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

E>>>>Устройство индексов как кластерных. так и некластерных на уровне страниц приблизительно знаю. Однако вникнуть в суть совета и почему так не могу. Не могли бы вы разъяснить.
S>>>Некластерный индекс хранит на своих страницах ссылки на кластерный индекс (типа foreign key). Чем короче кластерный индекс, тем меньше размер ссылки и тем больше индексов поместиться на каждой странице.
E>>Что значит "короче" приминительно к кластерному индексу?

_>короче = занимает меньше байт. int будет короче bigint и тем более uniqueidentifier.
м... я тоже так изначально подумал. А какая тогда разница? Будут ли страницы отсортированы по int или по char(...? На страницах(читай листьях индекса) так и сяк будут лежать все данные, все столбцы таблицы.

Может здесь имелся ввиду fillfactor?

IB пишет:

> MZ>И, кстати, лучше ещё и уникальный чтобы был.
> Это сделает кластерный индекс практически бесполезным для основной
> области его применения.

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

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

E>>>>>Устройство индексов как кластерных. так и некластерных на уровне страниц приблизительно знаю. Однако вникнуть в суть совета и почему так не могу. Не могли бы вы разъяснить.
S>>>>Некластерный индекс хранит на своих страницах ссылки на кластерный индекс (типа foreign key). Чем короче кластерный индекс, тем меньше размер ссылки и тем больше индексов поместиться на каждой странице.
E>>>Что значит "короче" приминительно к кластерному индексу?

_>>короче = занимает меньше байт. int будет короче bigint и тем более uniqueidentifier.
E>м... я тоже так изначально подумал. А какая тогда разница? Будут ли страницы отсортированы по int или по char(...? На страницах(читай листьях индекса) так и сяк будут лежать все данные, все столбцы таблицы.

При предположительном одинаковом fill factor, 8060 байт на страницу вместят 2015 int'ов (за точные цифры не ручаюсь, надо обратиться к документации, но суть думаю ясна). В случае uniqueidentifier (16 байт) это будет всего 503 uniqueidentifier'а. Стало быть при одинаковом количестве записей (например 1 млн) в первом случае индекс займет 496 страниц, а во втором — 1988 страниц. Стало быть при одинаковом запросе, которому для обращения к записям надо прочитать одинаковое количество записей из индексов — в случае uniqueidentifier в худшем случае придется прочитать в разы больше страниц с диска. Аналогично они же в памяти займут в разы больше места. Эффективность будет ниже короче.

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

_>При предположительном одинаковом fill factor, 8060 байт на страницу вместят 2015 int'ов (за точные цифры не ручаюсь, надо обратиться к документации, но суть думаю ясна). В случае uniqueidentifier (16 байт) это будет всего 503 uniqueidentifier'а. Стало быть при одинаковом количестве записей (например 1 млн) в первом случае индекс займет 496 страниц, а во втором — 1988 страниц. Стало быть при одинаковом запросе, которому для обращения к записям надо прочитать одинаковое количество записей из индексов — в случае uniqueidentifier в худшем случае придется прочитать в разы больше страниц с диска. Аналогично они же в памяти займут в разы больше места. Эффективность будет ниже короче.
ммм... а вот ты о чем... тогда ясно, согласен... Я почему-то подумал строить кластерный индекс либо по столбцу с int, либо по столбцу с uniqueidentifier, где оба из них есть в таблице... А так все ясно.

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

_>При предположительном одинаковом fill factor, 8060 байт на страницу вместят 2015 int'ов (за точные цифры не ручаюсь, надо обратиться к документации, но суть думаю ясна).
Ну, как минимум у каждой страницы есть заголовок, так что минус 93 байта в любом случае.

_> Стало быть при одинаковом запросе, которому для обращения к записям надо прочитать одинаковое количество записей из индексов — в случае uniqueidentifier в худшем случае придется прочитать в разы больше страниц с диска. Аналогично они же в памяти займут в разы больше места. Эффективность будет ниже короче.
Не все так плохо. На реальных задачах, на милионных таблицах больше 15% проигрыша GUID-ов int-ам мне получить не удавалось.

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

IB>Не все так плохо. На реальных задачах, на милионных таблицах больше 15% проигрыша GUID-ов int-ам мне получить не удавалось.

IB, объясните вы пожалуйста. Что такое короткий кластерный индекс? Что значит создавать короткий кластерный индекс? Ведь в случае с int и guid — я бы сказал относится больше к табличке. Тогда я бы сказал создавайте таблицы.... на которых построены кластерные индексы....

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

_>> Стало быть при одинаковом запросе, которому для обращения к записям надо прочитать одинаковое количество записей из индексов — в случае uniqueidentifier в худшем случае придется прочитать в разы больше страниц с диска. Аналогично они же в памяти займут в разы больше места. Эффективность будет ниже короче.
IB>Не все так плохо. На реальных задачах, на милионных таблицах больше 15% проигрыша GUID-ов int-ам мне получить не удавалось.

Гипотетически прозреваю снижение производительности при большом количестве джойнов (если все PK и FK — uniqueidentifier).

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

E>Что такое короткий кластерный индекс?
Это значит, что ключ индекса занимает мало места.

E>Что значит создавать короткий кластерный индекс?
Это значит выбирать ключем кластерного индекса данные меньшего размера.

E> Ведь в случае с int и guid — я бы сказал относится больше к табличке.
Нет, это относится к ключу. А еще точнее, к размеру остальных индексов.

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