Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Несколько глупых вопросов / 10 сообщений из 10, страница 1 из 1
02.12.2004, 14:59
    #32809813
еще один гость
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Несколько глупых вопросов
Заранее извиняюсь за тупые вопросы, подскажите пожалуйста, мне, жалкому ламеру с этим:

Какой смысл в использовании индексов по нескольким полям? В данном случае не идет речь о том, чтобы обеспечить уникальность записи по этим полям, а именно в плане увеличения скорости запросов. Что эффективней: построить по каждому полю свой индекс или один индекс на все?

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

И третье: почему кластерный индекс называется кластерным? Т.е. от слова "кластер" наверное... при чем тут кластеры? И чем кластерный лучше некластерного?
...
Рейтинг: 0 / 0
02.12.2004, 15:17
    #32809887
tygra
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Несколько глупых вопросов
Если проще сказать:
1. Индекс по нескольким полям помогает, если вы будете выбирать данные по тем же полям. Данные в индексе будут располагаться так же, как вы хотите их выбирать, следовательно операция пройдет за 1 действие :). По отдельным полям, индексы нужно еще пересечь между собой, чтобы попасть в условие выборки. Эффективность - зависит от условий выборки: последовательность полей, их количество и т.д. Конечно один индекс по всем полям не стоит делать :)

2. Если вам выбирать нужно по другомк порядку :)

3. Посмотрите перевод слова cluster. В кластерном индексе записи в таблице физически лежат в порядке индекса. Поэтому выборка по этому индексу будет идти быстрее - записи брать друг за другом. как они следуют

-- Tygra's --
...
Рейтинг: 0 / 0
02.12.2004, 15:44
    #32809960
еще один гость
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Несколько глупых вопросов
Большое спасибо за ответы. Просто я хотел бы сказать, что получается, что при создании индексов на этапе проектирования БД нельзя сказать, какими конкретно они должны обладать свойствами...

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

Вот встречались ли кому ситуации в практике, когда скажем порядок сортировки заранее известен? И каков должен быть объем данных, чтобы смена таких тонких настроек индекса дала заметный выигрыш в скорости?
...
Рейтинг: 0 / 0
02.12.2004, 15:54
    #32809993
olk
olk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Несколько глупых вопросов
На этапе проетирования можно ограничиться индексами по PK и возможно по FK, ну и так скажем индексы которые заведомо будут использованы
... в вашем варианте можно предположить что отбор по фамилии будет достаточно частой операцией, а возраст и пол обладают плохой селективностью и возможно индекс по ним бесполезен ...
все остальные индексы можно построить позже на этапе отладки и тьюнинга системы
...
Рейтинг: 0 / 0
02.12.2004, 16:30
    #32810104
еще один гость
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Несколько глупых вопросов
olk и возможно по FK
То есть по внешним ключам иногда индекс строить не нужно? Мне казалось, что индекс по этим полям обязателен.

Кстати о тьюнинге. В составе SQL Server есть такая вещь, как Index Tuning Index, или что-то в этом роде. Для своей работы он требует кусок лога работы профайлера. Правильно ли утверждать, что рекомендации это проги основаны именно на основе анализа условий после WHERE для SQL-запроса. Или изучением того, какие запросы часты, а какие нет, нужно заниматься самому?
...
Рейтинг: 0 / 0
02.12.2004, 16:46
    #32810157
olk
olk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Несколько глупых вопросов
Построение индекса для FK в теории не обязателен как кстати и по PK,
т.е. FK и PK - это в общем случае констрэйны ...
понятно что индексация по этим полям желательна но зависит и от конкретного сервера, например отсутствие индекса по FK в Oracle ведет к блокировки всей таблице ну и т.д.

про MS SQL Server & Index Tuning сказать со всей определенностью не могу,
но похоже на то раз он требует дамп профайлера хотя это не обязательно
условий после WHERE для SQL-запроса (возможно ему будет достаточно планов выполнения этих запросов) - честно говоря как устроен оптимизатор и профилер в MS SQL Server не в курсах
...
Рейтинг: 0 / 0
07.12.2004, 10:16
    #32815798
Осирис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Несколько глупых вопросов
Во-вторых: многие СУБД разрешают указывать порядок сортировки индекса. Наверно это зачем-то нужно... А зачем, подскажите пожалуйста.


Кстати, очень хороший вопрос. Если мы берем самый распространенный тип индекса - b-tree, то скорость поиска в нем не будет зависеть от того, как он построен - по убыванию или по возрастанию - на то оно и сбалансированное дерево.
...
Рейтинг: 0 / 0
07.12.2004, 10:44
    #32815901
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Несколько глупых вопросов
Какой смысл в использовании индексов по нескольким полям? В данном случае не идет речь о том, чтобы обеспечить уникальность записи по этим полям, а именно в плане увеличения скорости запросов.

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

Что эффективней: построить по каждому полю свой индекс или один индекс на все?
Для запросов по всем полям эффективнее составной индект.

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

Практически незачем, если СУБД умеет сканировать индексы в прямом и обратном направлении.

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

Кластер - это гроздь (как у винограда), пучёк и т.п . С теми кластерами (способ построения высокопроизводительных и высоконадежных вычислительных систем) это никак не связано.

Кластерный ничем не лучше некластерного, он просто другой. Кластерный физически сортирует данные в таблице, некластерный - не сортирует.
Соответственно, в каких-то ситуациях кластерный дает преимущество, в каких-то - недостатки.
Я бы сказал, что недостатков больше, но вполне можно найти ситуацию, в которой преимущества будут существенными.
...
Рейтинг: 0 / 0
07.12.2004, 11:00
    #32815967
LSV
LSV
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Несколько глупых вопросов
Кластерный для PK-автонумератора - самое то ! Скорость выше. Кластерный не расходует дополнительной дисковой памяти, т.к. сам является и индексом и данными. Однако вставка в такой индекс проходит медленее, т.к. надо поддерживать физическую сортировку данных в страницах.
...
Рейтинг: 0 / 0
07.12.2004, 12:44
    #32816296
ChA
ChA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Несколько глупых вопросов
LSVКластерный для PK-автонумератора - самое то !
Хороший способ получить "горячую" страницу, при активном добавлении новых записей в многопользовательском режиме.
LSV Скорость выше.Выше скорость чего ? И для кого ?
LSVКластерный не расходует дополнительной дисковой памяти, т.к. сам является и индексом и данными.Если для MS SQL, то не совсем верно, так как только листья могут быть страницами данных, узлы хранятся в отдельных страницах.
LSVОднако вставка в такой индекс проходит медленее, т.к. надо поддерживать физическую сортировку данных в страницах.
Опять же, если речь в контексте MS SQL, то может быть даже быстрее, так как в этом случае обычно происходит только вставка в нужную страницу данных, тогда как при использовании некластерного индекса 2 операции: вставка в страницу данных, вставка в страницу индекса. Надо учитывать еще то, что внутри страницы данных нет физического переупорядочивания при вставке, смотрите, например, Kalen Delaney - Inside SQL Server.

P.S. Суть кластерного индекса в том, чтобы держать рядом данные, которые чаще всего нужны одновременно и последовательно. Например, когда характерные запросы включают в себя between, по определенному полю или группе полей, или равенство, как вырожденный случай предыдущего. В этих случаях идет последовательное чтение страниц данных, что весьма положительно сказывается на производительности. Особенно хорошо, когда условие по выражению кластерного индекса включается в каждый запрос. Ккак упоминалось выше, кластерный индекс можно также использовать для уменьшения борьбы за страницу при активной многопоточной вставке.
В общем, не все так просто и однозначно, как у предыдущего оратора. В некоторых случаях хорошо подобранный кластерный индекс может привести к отказу от остальных индексов, разве что за исключением ограничений PRIMARY KEY и UNIQUE.
И последнее, кластерный индекс желательно делать уникальным самому, т.е.б ключом, добавляя в его конец уникальный идентификатор, тот же identity, например. По крайней мере, для MS SQL.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Несколько глупых вопросов / 10 сообщений из 10, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]