Microsoft SQL Serverの内部についてはわかりませんが、質問にタグを付けたMySQLについては回答できます。詳細は他の実装では異なる場合があります。
Q1。 そうです、クラスター化されたインデックスに余分なスペースは必要ありません。
クラスタ化されたインデックスを削除するとどうなりますか？ MySQLのInnoDBエンジンは、常に主キー（またはnull以外の最初の一意キー）をクラスター化インデックスとして使用します。主キーなしでテーブルを定義する場合、または既存のテーブルの主キーを削除する場合は、 InnoDBは、クラスター化インデックスの内部人工キーを生成します 。この内部キーには、それを参照するための論理列がありません。
Q2。 非クラスター化インデックスを使用するクエリによって返される行の順序は保証されません。実際には、これは行がアクセスされた順序です。行を特定の順序で返す必要がある場合は、ORDER BYを使用する必要があります クエリで。オプティマイザーが、目的の順序が行にアクセスする順序と同じであると推測できる場合（クラスター化インデックスか非クラスター化インデックスかを問わず、インデックスの順序）、並べ替え手順をスキップできます。
Q3。 InnoDB非クラスター化インデックスには、インデックスのリーフにある対応する行へのポインターがなく、値があります。 主キーの。したがって、非クラスター化インデックスでのルックアップは、実際には2つのBツリー検索であり、最初に非クラスター化インデックスのリーフを検索し、次にクラスター化インデックスで2番目の検索を行います。
これは、単一のBツリー検索の2倍のコスト（多かれ少なかれ）であるため、InnoDBにはアダプティブハッシュインデックス 。頻繁に検索される値はAHIにキャッシュされ、次にクエリがキャッシュされた値を検索するときに、O（1）ルックアップを実行できます。 AHIキャッシュでは、クラスター化インデックスのリーフへのポインターが直接検出されるため、両方が削除されます。 Bツリー検索、一部の時間。
これにより全体のパフォーマンスがどの程度向上するかは、以前に検索した同じ値を検索する頻度によって異なります。私の経験では、ハッシュ検索と非ハッシュ検索の比率は約1：2であるのが一般的です。
Q4。 最適化する必要のあるクエリを提供するためのインデックスを作成します。通常、クラスター化インデックスはプライマリキーまたは一意キーであり、少なくともInnoDBの場合は、これが必要です。どちらのage salaryも ユニークである可能性が高いです。
私のプレゼンテーション、インデックスの設計方法、本当に> 。
Q5。 一意の制約を宣言すると、InnoDBは自動的にインデックスを作成します。インデックスが存在しないと、制約を持つことはできません。インデックスがない場合、値を挿入するときにエンジンはどのように一意性を保証しますか？テーブル全体で、その列の重複する値を検索する必要があります。インデックスは、一意のチェックをはるかに効率的にするのに役立ちます。