AS
То есть в такой ситуации кластерный индекс имеет выигрыш перед некластерным, верно?
в такой ситуации записи локализуются физически по указанному тобой в индексе полю, как бы кластерный индекс разделяет множество твоих данных на физические корзины
Size: a a a
2021 March 11
В
ну давай на примере. есть районы города. твоя система работает с районом, то район отличный кандидат на кластерный индекс, почему? потому что все твои регулярные запросы будут иметь район в качестве одного из фильтрующий полей. это значит, что СУБД будет работать с данными локализованными физически в одном "кластере", районе, а не носится по диску в поисках физических записей, разбросанных как бог на душу положит.
и если рассмотреть ситуацию, что город - Москва и у нас районы добавляются просто постоянно ?
тогда какой из индексов покажет себя лучше?
тогда какой из индексов покажет себя лучше?
В
ведь по идее кластерный индекс будет перестраиваться с каждым инсертом (это как я понимаю)
AS
ведь по идее кластерный индекс будет перестраиваться с каждым инсертом (это как я понимаю)
кластерный индекс управляет физическим расположением записей.
A
а какой индекс не будет перестраиваться с каждым инсертом?))
В
Adv0cat
а какой индекс не будет перестраиваться с каждым инсертом?))
да, перестраивается и тот и тот, разница в том что один хранит указатели - а другой данные хранит физически и поэтому мне немного не понятно - для какого индекса эта операция будет менее затратна ?
AS
есть у тебя 10 районов, на каждый район будет создана своя корзина, и записи будут распределяться по корзинам в зависимости от значения поля район. добавится новый район, СУБД создаст новую корзину и будет помещать записи туда
В
есть у тебя 10 районов, на каждый район будет создана своя корзина, и записи будут распределяться по корзинам в зависимости от значения поля район. добавится новый район, СУБД создаст новую корзину и будет помещать записи туда
ааа
В
понятно
В
есть у тебя 10 районов, на каждый район будет создана своя корзина, и записи будут распределяться по корзинам в зависимости от значения поля район. добавится новый район, СУБД создаст новую корзину и будет помещать записи туда
но тогда следующий вопрос: не считая того что кластерный индекс можно построить один на таблицу, в каких случаях тогда будет предпочтительнее некластерный индекс ?
AS
но тогда следующий вопрос: не считая того что кластерный индекс можно построить один на таблицу, в каких случаях тогда будет предпочтительнее некластерный индекс ?
если ты понял про кластерный индекс, то тогда непонятен твой вопрос про некластерный.
AS
обычный индекс ты строишь для тех полей регулярных запросов, которые участвуют в where, group by
AS
ты выбрал выражение для кластерного, тем самым распределив записи физически
В
ты выбрал выражение для кластерного, тем самым распределив записи физически
а, все
вопрос теперь точно отпал
вопрос теперь точно отпал
AS
все остальное уже твоя борьба за перфоманс запросов
YS
Всем привет, народ
Может кто-то обьяснить в какой ситуации нужно строить кластерные индексы, а в какой некластерные?
Их отличия я знаю, но что-то непонятно пока для меня когда какие использовать
Может кто-то обьяснить в какой ситуации нужно строить кластерные индексы, а в какой некластерные?
Их отличия я знаю, но что-то непонятно пока для меня когда какие использовать
А СУБД-то какая, на всякий случай (вдруг не MS SQL)?
В
Yaroslav Schekin
А СУБД-то какая, на всякий случай (вдруг не MS SQL)?
MS)
YS
MS)
Ну так там clustered index — это knee-jerk reaction best practice по умолчанию, если я правильно помню. ;)
Можно и "наколоться", конечно — https://use-the-index-luke.com/blog/2014-01/unreasonable-defaults-primary-key-clustering-key
И я подобные случаи видел на практике, кстати.
Можно и "наколоться", конечно — https://use-the-index-luke.com/blog/2014-01/unreasonable-defaults-primary-key-clustering-key
И я подобные случаи видел на практике, кстати.
В
Yaroslav Schekin
Ну так там clustered index — это knee-jerk reaction best practice по умолчанию, если я правильно помню. ;)
Можно и "наколоться", конечно — https://use-the-index-luke.com/blog/2014-01/unreasonable-defaults-primary-key-clustering-key
И я подобные случаи видел на практике, кстати.
Можно и "наколоться", конечно — https://use-the-index-luke.com/blog/2014-01/unreasonable-defaults-primary-key-clustering-key
И я подобные случаи видел на практике, кстати.
то есть я правильно понял что комбинировать кластерные индексы и обычные в одной таблице - это не самый лучший подход?
YS
то есть я правильно понял что комбинировать кластерные индексы и обычные в одной таблице - это не самый лучший подход?
В смысле "индексы"? "Кластерный индекс" только один, а остальное зависит от ситуации — я же про это и дал ссылку.