Вы можете легко определить первую часть этого для себя
create table x
(
id int primary key
)
select * from sys.indexes where object_id = object_id('x')
Придает
object_id name index_id type type_desc is_unique data_space_id ignore_dup_key is_primary_key is_unique_constraint fill_factor is_padded is_disabled is_hypothetical allow_row_locks allow_page_locks
1653580929 PK__x__6383C8BA 1 1 CLUSTERED 1 1 0 1 0 0 0 0 0 1 1
Редактировать: Есть еще один случай, который я должен был упомянуть
create table t2 (id int not null, cx int)
create clustered index ixc on dbo.t2 (cx asc)
alter table dbo.t2 add constraint pk_t2 primary key (id)
select * from sys.indexes where object_id = object_id('t2')
Придает
object_id name index_id type type_desc is_unique data_space_id ignore_dup_key is_primary_key is_unique_constraint fill_factor is_padded is_disabled is_hypothetical allow_row_locks allow_page_locks has_filter filter_definition
----------- ------------------------------ ----------- ---- ------------------------------ --------- ------------- -------------- -------------- -------------------- ----------- --------- ----------- --------------- --------------- ---------------- ---------- ------------------------------
34099162 ixc 1 1 CLUSTERED 0 1 0 0 0 0 0 0 0 1 1 0 NULL
34099162 pk_t2 2 2 NONCLUSTERED 1 1 0 1 0 0 0 0 0 1 1 0 NULL
Что касается второй части, то здесь нет золотого правила, это зависит от вашей индивидуальной рабочей нагрузки и от того, какой у вас ПК.
Для удовлетворения индивидуальных поисков по первичному ключу подойдет некластеризованный индекс. Если вы выполняете запросы к диапазонам, они будут хорошо обслуживаться соответствующим кластеризованным индексом, но может также подойти закрывающий некластеризованный индекс.
Вам также необходимо учитывать ширину индекса кластеризованного индекса, в частности, поскольку он влияет на все ваши некластеризованные индексы и влияние вставок на разбиения страниц.
Рекомендую книгу Оптимизация производительности запросов SQL Server 2008 , чтобы узнать больше о проблемах.