5

1 TB、600 mの行のテーブルがあり、インデックス付きの列、具体的には選択クエリで使用されない主キー列のクラスター化インデックスの選択が誤っています。

この行からクラスター化インデックスを削除し、他のいくつかの行に作成したいと思います。

テーブルは現在次のようになっています。

  • colA（PK、nvarchar（3））[クラスター化されたインデックスpt b]

  • colB（PK、bigint）[クラスター化されたインデックスpt a]

  • colC（DateTime）[非クラスター化インデックス]

  • colD（お金）[非クラスター化インデックス]

  • colE（ビット）[インデックスなし]

  • colF（ビット）[インデックスなし]

  • colG（int）[インデックスなし]

  • より多くのインデックス付けされていない列

次のように変更したいと思います。

  • colA（PK、nvarchar（3））[クラスター化されたインデックスpt a]

  • colB（PK、bigint）[非クラスター化インデックス]

  • colC（DateTime）[非クラスター化インデックス]

  • colD（お金）[クラスター化されたインデックスpt d]

  • colE（ビット）[クラスター化されたインデックスpt b]

  • colF（ビット）[クラスター化されたインデックスpt c]

  • colG（int）[clustered index pt e]

  • より多くのインデックス付けされていない列

2つの質問：1）この変更にかかる時間はどれくらいだと思いますか（メッセージの最後にあるサーバーの仕様）。残念ながら、これはライブDBであり、どのくらいの期間ダウンするかをある程度把握していなければ、ダウンタイムを発生させることはできません。

2）クラスター化インデックスに非常に多くの列を追加するのはひどい考えですか？更新はほとんど実行されません。多くの挿入と選択があり、提案されたすべてのインデックス付き行を常に選択パラメーターとして使用します。

サーバー仕様：RAID5の5x 15kRPMドライブ、MS-SQL Sever 2005、およびそれらを実行し続けるためのいくつかのビット。

4

8 に答える 8

10

1 つには、クラスター化されたインデックスを絶対に必要以上に広くすることは避けます。5部構成にするのは逆効果に思えます。この複合クラスター化インデックスのすべての列は安定していますか?たとえば、変更されませんか??

そうでなければ、私はそれらを何としても避けます。クラスタ化インデックスは次のようにする必要があります。

  • 個性的
  • 安定
  • できるだけ狭く

クラスター化されていないインデックスを変更できます-問題ありません。ただし、クラスター化インデックスが乱雑になることは避けてください。それは間違いなくあなたのパフォーマンスを低下させます！

索引付けに関する Kimberly Tripp の優れたブログ記事をチェックしてください。

マルク

于 2009-03-27T16:38:28.663 に答える
6

変更を加えましたが、それほど時間はかかりませんでした。各操作の時間は次のとおりです。1回目は単一の7200RPMドライブを備えたバックアップサーバーで実行され、2回目はRAIDで15kドライブを備えたメインサーバーで実行されます。

ALTER TABLE Table DROP CONSTRAINT [PK_Table]

2:39時間/19分

CREATE CLUSTERED INDEX [IX_Clustered] ON [Table] 
(
 [a] ASC,
 [b] ASC,
 [c] ASC,
 [d] ASC,
 [e] ASC,
 [f] ASC
)WITH (PAD_INDEX  = ON, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, IGNORE_DUP_KEY = OFF, FILLFACTOR = 90, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = OFF) ON [PRIMARY]

15:30時間/2時間

ALTER TABLE Table ADD CONSTRAINT
PK_hands PRIMARY KEY NONCLUSTERED 
(
 e,
 h
) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

4時間/1時間

現在最も頻繁に使用されている選択クエリは10秒未満で、以前は10〜15分かかっていました。素晴らしい改善です！挿入時間も少し速いようです。

于 2009-04-05T00:32:58.157 に答える
3

ライブデータベースのコピーでこれを試すために使用できる、同様の仕様の開発環境が必要です。

于 2009-03-27T16:35:52.663 に答える
2

クラスター化されたインデックスを変更することは確かにここで役立つように聞こえますが、最初に（クラスター化されていない）カバーするインデックスを追加してみませんか？

新しいインデックスが作成されている間はテーブルを削除しないでください。また、パフォーマンスの向上（ある場合）によってこの再編成が行われることを示す必要があります。

于 2009-03-27T17:09:07.560 に答える
0

ディスク容量がある場合にできることの 1 つは、適切なクラスター化インデックスを使用して 2 つ目のテーブルを作成し、インクリメンタル プロセスを介して数日間にわたって行を新しいテーブルにコピーすることです。すべての行が存在したら、両方のテーブルで sp_rename を実行します (これには数分のダウンタイムが必要です。アプリが物理テーブルではなくビューを参照している場合、アプリのダウンタイムなしでこれを実行できます。これが役立つことを願っています) .

[編集] 行の更新にも対処する必要があります。すべての行をコピーしたら更新を同期できるように、ソース テーブルでタイムスタンプまたは最後に更新されたフィールドを使用できるようにする必要があります。

于 2009-03-27T16:36:27.373 に答える
0

1) この変更にはどれくらいの時間がかかると予想されますか (メッセージの最後にあるサーバーの仕様)。残念ながら、これはライブ DB であり、どれくらいダウンするかを考えずにダウンタイムを持つことはできません。

それは本当に、本当にデータに依存します。テーブル パラメータだけでは十分な情報が得られません。数分 (可能性は低い) から数日 (可能性は低い) になる可能性があり、最も可能性の高い時間はその間のどこかです。

2) クラスター化されたインデックスに非常に多くの列を追加するのはひどい考えですか? 更新はほとんど実行されません。提案されたすべてのインデックス付き行を選択パラメーターとして常に使用する、多くの挿入と多くの選択があります。

いいえ、問題はありません。更新をほとんど行わない場合にのみ、パフォーマンスが向上します。ただし、これらの更新が発生すると、インデックスを修正するのにしばらく時間がかかり、その間、パフォーマンスが低下しますが、これはデータによって異なります。

-アダム

于 2009-03-27T16:41:23.947 に答える
0

Brian に同意します。同じ量のデータを含むテスト データベースを用意し、インデックスの変更を実行する必要があります。しかし、クエリが高速化されると考えているため、この変更を行っていると思います。ベンチマーク テスト (インデックス変更の前後) を実行し、最適化が悲観化にならないようにする必要があります。

于 2009-03-27T17:31:42.030 に答える
0

変更をライブで(ダウンタイムなしで)実行できる可能性があるため、ダウンタイムについて心配する必要はないかもしれません。SQL Server 2005 Enterprise エディションに適用されます。

于 2009-03-27T16:34:34.243 に答える