データウェアハウス環境（SQL Server 2008）で作業しており、約200万行と20列のテーブルがいくつかあります。毎晩、テーブルはドロップされ、再作成されます。それらが作られると、インデックスも作られます。なんらかの理由で、これらの表にクラスタード・インデックスはありません。ただし、一意のノンクラスタード・インデックスがあります。論理的ではないようだ。誰もがそのすべてを変更することの不利な点を知っているので、これらのテーブルすべてにクラスタ化インデックスがあります。いくつかの領域を節約し、より良い実行する必要があります。SQL Serverテーブル内のクラスタ化インデックスと非クラスタ化インデックス
ヒント？
ありがとうございます。
実際、クラスタ化インデックスにも欠点があります。
私が最も過小評価している欠点は、クラスタ化インデックスペナルティです。
あなたがテーブルの上に任意のクラスタ化インデックスを持っていない場合、それはテーブルがヒープテーブルとして格納されることを意味します。すべての非クラスタ化インデックスは、そのヒープテーブルを参照します。
ヒープテーブルの良い点は、すべての行がいつでも別の物理的な場所に移動できるクラスタ化されたインデックスとは異なり、その中に格納された行がほとんど移動しないことです。
この違いは、ヒープまたはクラスタ化インデックスの行を参照するため、非クラスタ化インデックスに影響します。ヒープの場合は、その行の物理的な場所をクラスタ化されていないインデックスに格納できますこれまでに変わる）。クラスタ化インデックスがある場合、非クラスタ化インデックスにはクラスタ化キーが格納されます。
最終的にクラスタ化されていないインデックスを使用している場合は、ヒープまたはクラスタ化インデックスのいずれかで実際のテーブルに到達するための努力は非常に異なります。ヒープの場合、クラスタ化インデックスを持つ物理I/Clustered Index Seekを実行する必要があります。これは、通常、3〜5論理IO（表のサイズによって異なります）です。
クラスタ化されていないインデックスが多数あり、インデックスのみのスキャンがない場合（つまり、RIDアクセスが続くことを意味します）、クラスタ化インデックスはパフォーマンスを大幅に低下させる可能性があります。私が書いたこの記事ではそのことについて
詳細：
http://use-the-index-luke.com/blog/2014-01/unreasonable-defaults-primary-key-clustering-key
は、私の知る限り、SQL Serverの_all_のテーブルは、次のようなものを宣言するかどうかにかかわらず、クラスタ化インデックスを持っています。 –
@TimBiegeleisen：それは本当だとは思わない。 PKを「非クラスタ化」として作成すると、SQL Serverは非表示のクラスタ化インデックスを作成しません。あなたは多分それをMySQLと混同していますか？ –
@a_horse_with_no_nameデフォルトでは、SQL Serverはバックグラウンドでクラスタ化インデックスを作成します（[ここをクリック]（http://www.sqlpassion.at/archive/2015/06/29/primary-key-vs-clustered-index/） ）。別の名前付きインデックスを作成する以外に、これを無効にすることができますか？ –