Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
какой выбрать индекс? кластернй или некластерный?
|
|||
|---|---|---|---|
|
#18+
здраствуйте все!!! еще раз. читал читал Букс Онлайн про индексы и еще больщше запутался. у меня есть некая таблица: \nTelefons ( Id Int Not Null Identity(1,1), Firm_Id Int Not Null, Number Varchar(14) Not Null, Description Varchar(50) Null, CONSTRAINT Pk_Telefons PRIMARY KEY CLUSTERED (Id), CONSTRAINT Fk_Telefons FOREIGN KEY (Firm_Id) REFERENCES Firms(Id) ) также есть такие вот условия А. записи в таблице Telefons будут только читаться и очень очень редко изменяться Б. основные типы запросов это поиск телефонов фирмы \nSelect Number as 'Телефон', Description as 'Описание' from Telefons where Firm_Id = id_фирмы или поиск фирмы по телефону \nSelect Firm_Id from Telefons where Number LIKE %некий_телефон% соотношение числа запросов примерно 50 на 50 я так думал что лучше всего кластерный индекс по полю Id и некластерный по полям (Firm_Id, Number) не буду говорить почему я так подумал потому что я все равно не прав большое спасибо ответившим!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2002, 04:03 |
|
||
|
какой выбрать индекс? кластернй или некластерный?
|
|||
|---|---|---|---|
|
#18+
Я предполагаю, что в таблице не может быть записей с одинаковыми полями Firm_id и Number, поэтому я бы сделал кластерный индекс по этим двум полям, так как в запросах используются только эти два поля. А поле Id я бы убрал совсем (смысла в нем не вижу, тем более в индексировании этого поля), но если оно так сильно нужно, то по нему можно сделать некластерный индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2002, 06:16 |
|
||
|
какой выбрать индекс? кластернй или некластерный?
|
|||
|---|---|---|---|
|
#18+
IMHO Для приведенных запросов я бы предложил - кластерный индекс по Firm_Id с Fill Factor скажем 95% на случай, если у вас предусмотрено каскадное обновление PK-FK ключей (можно и меньше в зависимости от частоты обновления. По идеи, если у вас Firms(Id) сурогатный ключ, то каскадных обновлений быть не должно) - простой индекс по Number, т.к. наверное номера телефонов будут меняться чаще. Однако при добавлении во второй запрос сортировки по Firm_Id данный индекс не будет использован (при наличии первого индекса) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2002, 07:24 |
|
||
|
какой выбрать индекс? кластернй или некластерный?
|
|||
|---|---|---|---|
|
#18+
Сам подумай как соотносятся твои данные с двумя фактами: 1)Кластерные индексы эффективно используются для выборки большого кол-ва записей по индексному полю(типа where >6) 2)При создании кластерного индекса по уникально-возрастающему полю возникает хот-спот когда несколько пользователей добавляют записи (а данные в кластерном индексе должны добавляться в "конец").Из за этого падает производительность операций вставки. После этого добавить нечего... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2002, 13:07 |
|
||
|
какой выбрать индекс? кластернй или некластерный?
|
|||
|---|---|---|---|
|
#18+
Уже в 6.5 для инсерта был сделан уровень блокировки ROWLOCK. Так что hotspot при инсёрте сейчас не актуален. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2002, 14:01 |
|
||
|
какой выбрать индекс? кластернй или некластерный?
|
|||
|---|---|---|---|
|
#18+
Не вижу в посте автора ссылки на версию SQL с одной стороны.С другой стороны насколько я знаю не с 6.5 а с 7-ой. Ну и наконец независимо от внесенных MS изменений (безусловно в лучшую сторону) вопрос актуален до сих пор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2002, 18:09 |
|
||
|
какой выбрать индекс? кластернй или некластерный?
|
|||
|---|---|---|---|
|
#18+
сорри холонулся!!! все под MSSQL 2000 SP2 > А поле Id я бы убрал совсем (смысла в нем не вижу, тем более в индексировании этого поля), но его нельзя убирать т/к оно иснользуется на VB клиенте которого писал не я. Он(клиент) работает так: к примеру юзер хочет отредактировать телефон фирмы или удалить его, тогда из клиента в запросе возвращается Id телефона и его новое значение. По моему это естественно через Id телефона??? для Glory: > кластерный индекс по Firm_Id с Fill Factor вот я и подумал что кластерный индекс здесь будет нееэфективен в случае обоих запросов и вот почему..... (c)Ипатько Игорь, БОЛ: Сам подумай как соотносятся твои данные с двумя фактами: 1)Кластерные индексы эффективно используются для выборки большого кол-ва записей по индексному полю(типа where >6) 2)для запросов с наложением индексов (index covered queries) типа 2 (Select Firm_Id from Telefons where Number LIKE %некий_телефон%) рекомендуется использовать Некластерный индекс. Но это еще не все т/к там же в БОЛ говорится что в запросах типа с Where Name LIKE '%литерал%' оптимизатор не использует индекс (т/е запрос должен быть типа Where Name LIKE 'литерал%') для Ипатько Игорь: 2)При создании кластерного индекса по уникально-возрастающему полю возникает хот-спот когда несколько пользователей добавляют записи (а данные в кластерном индексе должны добавляться в "конец").Из за этого падает производительность операций вставки. нет, здесь до хот-спота далеко так как число фирм будет точно меньше чем может храниться в Int'е. Также повторюсь что операций вставки практически не будет С уважением, Дмитрий (администратор) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2002, 13:20 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32030555&tid=1822687]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
60ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 262ms |
| total: | 437ms |

| 0 / 0 |
