Всем привет, народ Может кто-то обьяснить в какой ситуации нужно

строить кластерные индексы, а в какой некластерные?
Их отличия я знаю, но что-то непонятно пока для меня когда какие использовать

ну давай на примере. есть районы города. твоя система работает с районом, то район отличный кандидат на кластерный индекс, почему? потому что все твои регулярные запросы будут иметь район в качестве одного из фильтрующий полей. это значит, что СУБД будет работать с данными локализованными физически в одном "кластере", районе, а не носится по диску в поисках физических записей, разбросанных как бог на душу положит.

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

в такой ситуации записи локализуются физически по указанному тобой в индексе полю, как бы кластерный индекс разделяет множество твоих данных на физические корзины

и если рассмотреть ситуацию, что город - Москва и у нас районы добавляются просто постоянно ? тогда какой из индексов покажет себя лучше?

А СУБД-то какая, на всякий случай (вдруг не MS SQL)?

MS)

Ну так там clustered index — это knee-jerk reaction best practice по умолчанию, если я правильно помню. ;) Можно и "наколоться", конечно — https://use-the-index-luke.com/blog/2014-01/unreasonable-defaults-primary-key-clustering-key И я подобные случаи видел на практике, кстати.

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

В смысле "индексы"? "Кластерный индекс" только один, а остальное зависит от ситуации — я же про это и дал ссылку.

ТУПО: для PK - кластерный, для всего остального — нет. СОВСЕМ ТУПО: не знаешь, какой индекс делать кластерным — делай все некластерными. ПО-УМНОМУ: если надо делать большие range scan -ы по индексу — делай его кластерным. Но повезёт только один раз...

Кластерный перед некластерным вообще имеет очень маленький выигрышь, хотя и имеет конечно, но у него есть один существенный недостаток (у кластерного) - он в таблице может быть ТОЛЬКО ОДИН.

Хорошо, а если представим ситуацию такую Вот есть у нас мессенджер, есть какая-то таблица сообщений с 10 миллионами записей Мы зафигачили кластер-индекс по диалогу например К примеру у нас есть диалог с миллионом записей - то есть какая-то выборка по нему будет все равно не очень быстрая И мне например надо там еще выбирать по каким-то свойствам сообщения с этого диалога (по каким сложно придумать, но пусть этих свойств еще будет 3) Стоит ли строить некластерный индекс по этим полям в такой ситуации?

А сейчас уже почти всё равно... очень расхожая схема сейчас у многих СУБД — кластерный PK

Стоит ли строить (некластерный) индекс по этим полям в такой ситуации? — это вообще другой, совершенно отдельный вопрос. НИКАК не связанный с предыдущим вопросом.

Судя по всему, тебе подойдёт, на твоём уровне понимания, пункт "ТУПО" , тем более, что SQLServer

Там в диалогах текст Идексы текста работают по другому Наверняка этот индекс будет отдельным столбцом в таблице Или типа того Вроде

И вот ровно с таким подходом (на уровне коленного рефлекса) я и видел ситуации (суть которых описана по ссылке), когда "умница"-консультант или DBA, глядя на heap-таблицу с десятком индексов, говорил "ну что же вы, это же плохая практика! Срочно переделать!"... и после внедрения "улучшения" производительность падала в разы. ;) Так что лучше думать, если ситуация такая, когда это может иметь значение, вот в чём был мой посыл.

я имею ввиду не по тексту выборку делаем, а по каким-то абстрактным свойствам ну, например, какое сообщение не прочитано и так далее, это вообще не важно сложно придумать просто свойства сообщений)

Так это был наверное консультант по SQLServer...

Ярослав, там же был и пункт "СОВСЕМ ТУПО"

Да. А где ещё "основное" название index-organized table сейчас "кластерный индекс", кстати?

Сложно говорить о индексах абстрактно...

Везде, кроме оракла и PG... AFAIK

Хорошо, ок Пусть будет делаем выборку в этом диалоге (это будет груповой чат) сообщений, которые были прочитаны и которые написали женщины допустим Так лучше ?

Я каждый запрос из моих сервисов к бд проверяю руками Смотрю где индексы настроены, а где нужно настроить И да, это ведет к большему количеству индексов чем вроде как нужно Но я ж могу добавить всегда шард на запись А если все совсем плохо станет, то позвать консультанта :)

Нет, хуже. Индекс не нужен для этих условий.

Я понимаю что не нужен так как это булевые значения

Да, похоже на то, спасибо! Всё-таки не очень удачное название (по самому названию непонятно, что это такое... а некоторые и вовсе понимают иначе), IMHO.

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

В моем понимании для более быстрой выборки

отлично