回答:
それらは一意である必要はありませんが、確かに推奨されます。
一意でない列にCIを作成したいというシナリオはまだ発生していません。
クラスター化インデックスが一意のインデックスでない場合、SQL Serverは、一意化子と呼ばれる内部で生成された値を追加することにより、重複するキーを一意にします
これはパフォーマンスの低下につながりますか？
一意化子を追加すると、計算と保存にある程度のオーバーヘッドが確実に追加されます。
このオーバーヘッドが目立つかどうかは、いくつかの要因によって異なります。
Remusがコメントで指摘しているように編集しますが、一意でないCIを作成することが合理的な選択となるユースケースが存在します。これらのシナリオの1つに遭遇しなかった私は、単に私自身の露出または能力の欠如を示しています（選択してください）。
インデックス作成の女王、キンバリー・トリップがこのトピックについて何と言っているかを確認したいと思います。
いくつかの理由から、クラスタリングキーの推奨事項から始めます。まず、決定は簡単です。次に、この決定を早期に行うことで、特定の種類の断片化を予防的に防ぐことができます。特定の種類のベーステーブルの断片化を防ぐことができる場合は、テーブルをオフラインにする必要があるいくつかのメンテナンスアクティビティ（SQL Server 2000では一部、SQL Server 2005ではそれ以下）を最小限に抑えることができます。OK、後で再構築するものに行きます.....
クラスタリングキーで私が探す重要なことから始めましょう：
* Unique
* Narrow
* Static
なぜユニークなのですか？ クラスタリングキー（存在する場合）は、すべての非クラスター化インデックスからのルックアップキーとして使用されるため、クラスタリングキーは一意である必要があります。たとえば、本の裏にあるインデックス（インデックスエントリが指すデータを見つける必要がある場合）を例にとると、そのエントリ（インデックスエントリ）は一意である必要があります。そうでない場合、どのインデックスエントリが探しているのでしょうか。 ？したがって、クラスター化インデックスを作成するときは、一意である必要があります。ただし、SQL Serverでは、クラスタリングキーを一意の列に作成する必要はありません。任意の列に作成できます。内部的には、クラスタリングキーが一意でない場合、SQLServerは4バイト整数をデータに追加することによってそれを「一意化」します。したがって、クラスター化インデックスが一意ではないものに作成された場合、インデックス作成時に追加のオーバーヘッドが発生するだけでなく、無駄なディスク領域が発生します。
newsequentialid()ほぼシーケンシャルなGUIDを取得するために使用すると彼女は言います。ただし、はい。独自のIDを追加すると（私は常にINT IDENTITYを好みます）、その値が手元にあり、それを使用できます（たとえば、FK関係を確立するため）。SQL Serverで追加された一意のファイアは表示されないため、使用できないオーバーヘッドにすぎません。
クラスター化インデックスは一意である必要がありますか？
そうではなく、そうでない方が良い場合もあります。
半ランダムで一意のEmployeeIdと各従業員のDepartmentIdを持つテーブルについて考えてみます。selectステートメントが
SELECT * FROM EmployeeTable WHERE DepartmentId=%DepartmentValue%
次にDepartmentId、が一意のインデックスではない場合でも（または特に理由で）、がクラスター化インデックスである場合、パフォーマンスに最適です（特定のDepartmentId内のすべてのレコードがクラスター化されるため、パフォーマンスに最適です）。
参考文献はありますか？
ありますクラスタ化インデックスの設計ガイドラインは、述べていた、例えば
いくつかの例外を除いて、すべてのテーブルには、以下を提供する1つまたは複数の列にクラスター化インデックスを定義する必要があります。
- 頻繁に使用されるクエリに使用できます。
- 高度な独自性を提供します。
- 範囲クエリで使用できます。
たとえば、「高度な一意性」についての私の理解は、クエリのほとんどが特定の町内のレコードを選択する場合、クラストインデックスとして「国」を選択するのは良くないということです。