Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Индексы - покрытие  [new]
[-==-]
Member

Откуда:
Сообщений: 190
Всем привет!
Подскажите, например имеем таблицу (1С 8):
	[_Period] [datetime] NOT NULL,
	[_RecorderTRef] [binary](4) NOT NULL,
	[_RecorderRRef] [binary](16) NOT NULL,
	[_LineNo] [numeric](9, 0) NOT NULL, 
        и т.д., большая

и в ней индексы:
CREATE UNIQUE CLUSTERED INDEX [_Index] ON [dbo].[_Table] 
(
	[_Period] ASC,
	[_RecorderTRef] ASC,
	[_RecorderRRef] ASC,
	[_LineNo] ASC

и
REATE UNIQUE NONCLUSTERED INDEX [_AccRg1037_ByRecorder_RN] ON [dbo].[_AccRg1037] 
(
	[_RecorderTRef] ASC,
	[_RecorderRRef] ASC,
	[_LineNo] ASC


Как по-вашему, является некластерный индекс излишним, т.к. в кластерном уже есть все эти поля?
13 апр 15, 16:51    [17509037]     Ответить | Цитировать Сообщить модератору
 Re: Индексы - покрытие  [new]
хмхмхм
Guest
[-==-],

второй индекс может быть полезен при поиске по трем полям, по первому полю из некластерного индекса или по двум первым полям (иначе без него будет скан кластерного индекса), в общем вам лучше знать какие запросы вы используете и лишний ли индекс.

Кстати, почему у вас у двух индексов разные таблицы:

ON [dbo].[_Table] 
ON [dbo].[_AccRg1037]

?
13 апр 15, 16:58    [17509067]     Ответить | Цитировать Сообщить модератору
 Re: Индексы - покрытие  [new]
WarAnt
Member

Откуда: Питер
Сообщений: 2421
[-==-],

Если поиск будет по полю [_RecorderTRef], а в выборке будут только [_RecorderRRef],[_LineNo] то не является.
А вообще это все гадание на КГ.
13 апр 15, 16:59    [17509080]     Ответить | Цитировать Сообщить модератору
 Re: Индексы - покрытие  [new]
o-o
Guest
[-==-],

так второй-то может не просто индекс,
а ограничение уникальности (unique constraint).
из того, что комбинация 4х полей уникальна,
не следует же автоматом, что и комбинация трех уникальна:

вот 4 дают уникальную комбинацию,
а без первого поля совсем нет:
(1, 0, 2, 3)
(2, 0, 2, 3)

тут скорее напрашивается вопрос, не является ли 1-ое поле кластерного излишним,
и ответ будет, да, является,
но может надо, чтобы вставки шли в конец кластерного,
а период как раз монотонно возрастает,
или какой-то range scan нужен по периоду,
поэтому так спроектировали
13 апр 15, 17:02    [17509095]     Ответить | Цитировать Сообщить модератору
 Re: Индексы - покрытие  [new]
[-==-]
Member

Откуда:
Сообщений: 190
Спасибо всем за ответы.
хмхмхм, имена таблиц одинаковые, это по ошибке, экспериментировал.
В моем случае 2 индекса (схематично):
1-2-3
и
2-3
Что мешает серверу использовать индекс "2-3", если уже есть "1-2-3"? Нельзя войти в дерево индекса на уровне 2?
14 апр 15, 09:19    [17511022]     Ответить | Цитировать Сообщить модератору
 Re: Индексы - покрытие  [new]
Glory
Member

Откуда:
Сообщений: 104760
|-==-|
Что мешает серверу использовать индекс "2-3", если уже есть "1-2-3"?

Статистика наверное

|-==-|
Нельзя войти в дерево индекса на уровне 2?

А как это сделать, не прочитав весь уровень 1 ?
14 апр 15, 09:23    [17511039]     Ответить | Цитировать Сообщить модератору
 Re: Индексы - покрытие  [new]
хмхмхм
Guest
[-==-],

o-o кстати прав, прислушайтесь.

По поводу что мешает использовать серверу индекс. Мешает то, что первый сегмент у вас другой. Вот если бы у вас был индекс f1+f2+f3, то запрос по условию f1 мог бы использовать этот индекс, запрос по двум условиям f1+f2 тоже, а вот f2+f3 уже бы его не использовал (ну если только он не кластерный конечно, но и там был бы скан, а не seek скорее всего).
14 апр 15, 10:03    [17511250]     Ответить | Цитировать Сообщить модератору
 Re: Индексы - покрытие  [new]
[-==-]
Member

Откуда:
Сообщений: 190
В целом ясно, спасибо всем.
14 апр 15, 10:33    [17511373]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить