0

特定のファイルがシステムによってチェックされるときに通過するステータスを追跡するテーブルがあります。次のようになります:
FileID int
Status tinyint
TouchedBy varchar(50)
TouchedWhen datetime

現在、このテーブルには主キーはありませんが、Status と TouchedWhen にはクラスター化されたインデックスがあります。

テーブルが拡大し続け、それに対するクエリのパフォーマンスが低下するにつれて、私が考えていたのは、PrimaryKey を追加して、ヒープ ルックアップ (FileID、Status、TouchedWhen の主キー) から抜け出すことです。

私が直面している問題は、TouchedWhen の丸めの問題が原因で、まったく同じ日時のエントリが 2 つある場合があります。

それで、それをdatetime2（7）に変換し、その時点で重複しているものを変更するのに何が必要かを調査し始めました。私のテーブルは次のようになります:
FileID int
Status tinyint
TouchedBy varchar(50)
TouchedWhen datetime2(7)

FileID、Status、TouchedWhen の主キー

私の質問はこれです-重複がある場合、既存のテーブルを通過してミリ秒を追加する最良の方法は何ですか? オンラインのままにしておく必要があるテーブルにこれを行うにはどうすればよいですか?

事前に、ありがとう、
ブレント

4

1 に答える 1

2

クエリを高速化するために主キーを追加する必要はありません。インデックスを追加するだけで、主キーを追加するのFileID, Status, TouchedWhenと同じくらいパフォーマンスに影響します。主キーを定義する主な利点は、自動インクリメント主キーを使用して達成できるレコード ID と参照整合性です。

(主キーを持つべきではないと言っているのではありません。主キーのパフォーマンスへの影響は、それが主キーであるという事実ではなく、インデックス自体にあると言っているのです)

一方、クラスター化インデックスを含めるように変更すると、これらの列を使用したルックアップでインデックスを検索してからデータをルックアップする必要がなくなるため、影響が大きくFileIDなる可能性があります。データ ページはインデックス値とともにすぐそこにあります。

于 2013-11-18T21:05:50.107 に答える