Запрос на поиск в таблице , у которой Primary Key - составной

Есть таблица :

CREATE TABLE [poper_RKK] (
[cur_nomer] [int] NOT NULL ,
[popered] [int] NOT NULL ,
[priz] [int] NOT NULL ,
[old_nomer] [char] (50) COLLATE Cyrillic_General_CI_AS NOT NULL ,
[R_Familia] [char] (20) COLLATE Cyrillic_General_CI_AS NULL ,
[R_Imia] [char] (15) COLLATE Cyrillic_General_CI_AS NULL ,
[R_Pattern] [char] (18) COLLATE Cyrillic_General_CI_AS NULL ,
[arc] [int] NULL ,
CONSTRAINT [PK_poper_RKK] PRIMARY KEY CLUSTERED
(
[cur_nomer],
[popered]
) WITH FILLFACTOR = 80 ON [PRIMARY]
) ON [PRIMARY]

Как видите, первичный ключ таблицы состоит из двух полей... А для чего ?
....а для того, что к этой таблице я обращаюсь исключительно запросом :

SELECT * FROM poper_RKK WHERE cur_nomer = @const1 AND popered = @const2

...надеясь на то , что умная (умный, умное-ее...? ) SQL скомпилирует запрос таким образом, что обратится к кластерному индексу этой таблицы по составному ключу из двух полей , указанных в условии, потому , что они совершенно случайно (вариант белого рояля в кустах !) соответствуют индексному ключу ...

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

Эмпирически определить это не могу - контрольный пример довольно маленький - несколько тисяч строк (идет разработка!) - но правильное решение хочется сейчас...

(Исходные данные : W2K Server SP2 , MS SQL 2000 SP3 )

Он (она, оно) в таких вопросах достаточно умный (-ая, -ое) и разберется, что к чему. Вместо PK достаточно создать обычный индекс.

Э-э-э, батенька-с... Вашей последней репризой вы желаете снова ввергнуть нас в пучину религиозного разбрата ( что хутчее : кластерный - обычный ?...)

Держимся стойко и не поддаемся... Я так себе тсинкаю ( в смысле миркую...) , что 1-2 пайджес на операциях И/О при кластерном я завсегда сэкономлю... ( ...что , согласитесь, всегда приятно !) ...

За сим на добром глаголе - спасибо...

Но, что-то в последнее время (наверное, осеннее-ее настроение) есть у меня сомнение

А что по этому поводу "говорит" план выполнения ??

...а Госплан выполнения грит, сукин кот, что "Clustered index seek".... Во, чаво делают, сникерсы жеванные...! Пры-ы-ыткие видать по всему...

За напоминалку, Глорию Форумичеву , кланяемся низенько и на полати - дивелопердить апликашку далее...

Опаньки, да тут дискуссия пошла. :) Ладно, поехали.

Про экономию 1-2 страниц при чтении всех и изменении неключевых полей согласен. При вставке и изменении ключа ситуация может резко изменится. В принципе можно сильно не беспокоится об этом, если бы на таблице висел обыкновенный идентити, однако в приведенной схеме этого не видно. Поэтому целесообразность введения именно кластерного индекса зависит от других причин, которые нужно дополнительно уточнять. Если база близка к readonly, то да. А на rowguid в OLTP вешать кластерный индекс мало кто будет. Ну ладно, развел я тут демагогию немножко, простите.

Для приведенной ситуации действительно достаточно обычного кластерного индекса. Дополнительное условие, что этот индекс является еще и PK избыточно. Вот, собственно, и все, что я хотел сказать. :)

Что касается необходимости применения хинтов - для данных запросов это излишне. При увеличении количества данных оптимизатор не поменяет своего мнения.