Можно также добавить, что часто это ПЛОХО, чтобы кластеризовать первичный ключ. В частности, когда первичный ключ назначается идентификатором IDENTITY, он не имеет внутреннего значения, поэтому любое усилие по правильному расположению таблицы будет напрасным.
Рассмотрим таблицу Product с ProductID INT IDENTITY PRIMARY KEY. Если это кластеризовано, то продукты, которые связаны каким-либо образом, могут распространяться по всему диску. Возможно, было бы лучше кластеризовать что-то, на что мы, вероятно, будем запрашивать информацию, например, ManufacturerID или CategoryID. В любом из этих случаев кластеризованный индекс (при прочих равных условиях) сделает соответствующий запрос намного более эффективным.
С другой стороны, внешний ключ в дочерней таблице, который указывает на это, может быть хорошим кандидатом для кластеризации (я возражаю против столбца, который на самом деле имеет атрибут IDENTITY, а не его родственников). Таким образом, в моем примере выше, вероятно, что ManufacturerID является внешним ключом для таблицы производителя, где он установлен как IDENTITY. Этот столбец не должен быть кластеризован, но столбец в Product, который ссылается на него, мог бы сделать это с хорошим преимуществом.