Пожалуйста, прочитайте мой ответ в разделе «Нет прямого доступа к строке данных в кластеризованной таблице - почему?» , сначала.
Если есть IAM, то есть индекс.
Но если CI отсутствует, то строки находятся в куче, и да, если вы хотите прочитать их напрямую (без использования NCI или там, где нет индексов), вы можете только сканировать таблицу в куче..
Кластерный индекс всегда лучше, чем его отсутствие.Существует одно исключение и одно предупреждение, как для ненормальных, так и для нестандартных условий:
Неуникальный ключ CI.Это вызывает переполнение страниц.Реляционные таблицы должны иметь уникальные ключи, поэтому это не Реляционная таблица.CI можно легко сделать уникальным, перегружая столбцы.Неуникальный CI все же лучше (согласно моему другому посту) иметь Неуникальный CI, чем не CI.
Monotonic Key.Обычно это столбец IDENTITY.Вместо случайных вставок, которые вставляют строки, распределенные по всей структуре хранения данных (как обычно с «хорошим» естественным реляционным ключом), вставленный ключ всегда находится на последней странице.Это вызывает горячую точку вставки и уменьшает параллелизм.Предполагается, что реляционные ключи уникальны;суррогат - это всегда дополнительный индекс.Только суррогат - это просто не реляционная таблица (это группа ненормализованных электронных таблиц с идентификаторами строк, связывающими их вместе; из этого вы не получите всю мощь базы данных)..
Таким образом, постоянный совет: используйте NCI для монотонных ключей и убедитесь, что КИ обеспечивает хорошее распределение данных.
Преимущества КИ огромны, а хороших нет.причина иметь одну (могут быть плохие причины, как указано выше).
CI разрешают запросы диапазона;NCI нет.Но это не единственная причина.
Еще одно предостережение: вам нужно сохранять небольшую ширину клавиши CI, поскольку она переносится в NCI.Теперь обычно это не проблема, так как широкие клавиши CI в порядке.Но там, где у вас есть Нормализованный набор электронных таблиц, маскирующихся под базу данных, что приводит к гораздо большему количеству индексов, чем нормализованная база данных, это действительно необходимо учитывать.Поэтому постоянный совет для преданных Империи: удерживайте клавишу CI нажатой.CI не «увеличивают» NCI, что не указано точно.Если у вас есть NCI, у него будет указатель или ключ CI;если у вас есть CI (со всеми преимуществами), то стоимость, ключ CI вместо RowId, ничтожна.Таким образом, точное утверждение заключается в том, что широкие ключи CI увеличивают NCI.
Тот, кто говорит, что последовательный доступ к CI не может быть распараллелен, неверен (MS может сломать его в одной версии и исправить в следующей, но это временно).).
При использовании нотации ANSI SQL ... PRIMARY KEY ... по умолчанию используется значение UNIQUE CLUSTERED.потому что БД должен быть реляционным.И уникальный ПК должен быть приятным дружественным ключом отношений, а не идиотским столбцом IDENTITY.Следовательно, неизменно (не считая исключений) PRIMARY KEY является лучшим кандидатом для кластеризации.
Вы всегда можете создавать любые индексы, которые хотите, избегая нотации ANSI SQL ... PRIMARY KEY ... и используя CREATE [UNIQUE] [CLUSTERED] INDEX обозначение вместо.
Невозможно ответить на последний ваш вопрос, вам придется продолжать задавать вопросы, пока не закончится.Но, пожалуйста, забудьте про документацию, на которую вы ссылаетесь, и начните заново, иначе мы будем здесь несколько дней, чтобы обсудить разницу между ясным знанием и гоблдогу.