2016-12-12 14 views
3

SQL Serverでは、クラスタインデックス定義に新しい列を1つ追加する場合、クラスタインデックスを変更するオプションはありません。唯一のオプションは、新しい定義でクラスター索引をドロップして作成することです。クラスタインデックスを高速化する方法

私が理解しているところでは、クラスター索引のドロップおよび作成は、大量表の場合には非常にコストがかかり時間がかかります。

クラスター索引再作成は、非常に高価な表のすべての非クラスター化索引を再構築します。

このフォーラムへの質問「であり、そこにとにかく、我々は再作成クラスタ索引スピードアップすることができます」私が考えることができるもの

1つの回避策は、クラスタ索引を再作成する前に、すべての非クラスタ索引をドロップすることです。このアプローチは機能しますか?

+0

* clustered *インデックスは、ディスク上のデータ自体を順序付けします。これを変更するということは、ディスク上のすべてのデータを並べ替えることを意味します。どのデータベースを使用していても、それは高価です。 SQL Server Enterprise Editionでは、ONLINE = ONヒントを使用してダウンタイムを回避することができます。 –

答えて

4

使用

CREATE .... WITH (DROP_EXISTING = ON) 

代わりの

DROP ... 
CREATE ... 

これは、非クラスタ化インデックスのみ(新しいキーの列を含めるように)一度に更新する必要があることを意味します。 2回ではなく、最初に物理的な除去を使用し、新しいCIキーを使用します。

DROP_EXISTING句が

..新しいものは、新しいクラスタ化インデックスが所定の位置になるまで、非クラスタ化インデックスを更新するSQL Serverの延期をさせる、その場所に追加されることを既存のクラスタ化インデックスが削除されているSQL Serverに指示しますが、

また、SQL Serverは、クラスタ化インデックスキーが変更されない場合は、まったく非クラスタ化インデックスを再構築しないであろうとUNIQUE

例として、クラスタ化インデックスを定義する明確なパフォーマンス上の利点ではありませんUNIQUEとして定義され、

CREATE TABLE #T 
(
A INT, 
B INT, 
C INT 
) 

CREATE CLUSTERED INDEX IX ON #T(A) 

CREATE CLUSTERED INDEX IX ON #T(A,B) WITH (DROP_EXISTING = ON) 

DROP TABLE #T 
+0

OPはバックグラウンドでインデックスを再構築し、ダウンタイムを回避するためにONLINE = ONヒントを追加できます。 –

+0

@PanagiotisKanavos再構築のプロセスではありません同じヒントを持つノンクラスタード・インデックスを構築するのに似た、ONLINE ONのクラスタード・インデックス? RDBMSが現行の索引から新しく作成された索引に切り替わるときの小さなダウンタイムがあるので、 –

+0

@RaduGheorghiuこのテーブルでは、クエリを実行できるようになっています。これは大きなテーブルを扱う際の大きな利点です。また、週末などの待つのではなく、すぐに変更を適用することもできます。 –

関連する問題