パーティション関数とクラスター化インデックス
Identity/datetime2でクラスター化されたテーブルがあります。同じdatetime2でパーティション化されています。代わりにdatetime2/identityでクラスター化する理由はありますか？クラスタリングの背後にある理由は一般的に理解していますが、パーティショニングが含まれていると、状況は変わりますか？
テーブルをパーティション化すると、パーティション関数に基づいてテーブルが「チャンク」に分割されるだけです。クラスタ化インデックスは、各パーティション内のデータに順序を与えます。
パーティションのpartsを含むクエリを実行する場合（つまり、1月5日から1月12日までの売上を表示する）、日付を先頭にすることがクエリにとって有利な場合があります。クラスタリングキーの列。このタイプの構造では、パーティションスキャンではなく、クラスター化インデックスシークが発生します。 （テーブルに他の適切なインデックスがないと仮定します。）
クエリがパーティション全体にのみ影響する場合は、パーティションを削除するだけで必要なデータを分離できるので、それほど問題にはなりません。とは言っても、最初に日付順にすると、実行している処理によっては、高価な並べ替え操作が不要になる場合があります。
しかし、これはテーブルからどの列が必要かにも依存します。日付範囲全体の総売上高の合計のようなものだけを行う必要がある場合は、テーブル全体を再構築するのではなく、日付をキーの先頭（または唯一）の列としてカバーする非クラスター化インデックスを使用するだけで十分な場合があります。それ。
クラスタ化インデックスを変更すると、非クラスタ化インデックスシーク+キールックアップが含まれるため、シングルトンルックアップ（おそらく私が主キーであると想定しているID列による）に影響します。このタイプのアクティビティがワークロードの主要な部分ではない場合、これは問題ありませんが、これらのクエリによって選択される行が多すぎないように十分に注意する必要があります。そうしないと、オプティマイザが想定に基づいてパーティションスキャンに戻ります。安いです。繰り返しになりますが、必要な列によっては、必要な列のみを含む非クラスター化インデックスを作成する方が有利な場合があります。