0

ユーザー ユーザーのコメントを格納するテーブルがあります。1億以上のコメントがあります。

2 つの方法で作成できます。

オプション 1: PK としてのユーザー名とコメント ID。こうすることで、すべてのコメントがユーザー名とコメント ID によって物理的に保存されます。

CREATE TABLE [dbo].[Comments](
    [user] [varchar](20) NOT NULL,
    [com_id] [int] IDENTITY(1,1) NOT NULL,
    [com_posted_by] [varchar](20) NOT NULL,
    [com_posted_on] [smalldatetime] NOT NULL CONSTRAINT DEFAULT (getdate()),
    [com_text] [nvarchar](225) COLLATE NOT NULL,
 CONSTRAINT [PK_channel_comments] PRIMARY KEY CLUSTERED 
 ([channel] ASC, [com_id] ASC) WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]) ON [PRIMARY]

長所: 私のクエリは、comment_id DESC によるユーザー オーダーのすべてまたは上位 10 件のコメントを取得します。これがSEEKです

オプション 2: コメント ID を PK にすることができます。これにより、ユーザー名ではなく、コメント ID で並べ替えられたコメントが保存されます。

短所: 特定のユーザーの最新の上位 10 件のコメントを取得することは、データがユーザー別に保存されていない (つまり、ユーザー別にソートされていない) ため、もはやシークではありません。そのため、クエリのパフォーマンスを向上させるために別のインデックスを作成する必要があります。

どの方法で進めるのが最善ですか？挿入と削除はどうですか？これらの操作は許可されています。でも読む頻度は高いです。

ユーザーはコメントを変更できません。

両方のテーブルを 110 万行でテストしました。結果は次のとおりです。

table_name  rows        reserved    data        index_size  unused
comments2   1079892     99488 KB    62824 KB    36576 KB    88 KB  (PK: com_id  Second Index on (user_name, com_id))
comments1   1079892     82376 KB    82040 KB    328 KB      8 KB   (PK: user_name, no other indices)
--------------------------------------------------------------------
diff:       same rows   17112KB     -19216KB    36,248KB    80KB

したがって、PK として com_id を持つテーブルは、2 つのインデックスのためだけに 36MB の余分なディスク領域を使用しています SEEK を使用して両方のテーブルでトップ クエリを選択しますが、PK として com_id を持つテーブルは遅くなりますが、PK として com_id を持つ場合、挿入はわずかに速くなります

コメントはありますか？

4

5 に答える 5

2

コメント ID をテーブルの主キーとして使用します。コメント ID とユーザー名を使用するクエリが多数ある場合は、それらのフィールドにインデックスを追加するだけで簡単になります。

于 2010-10-21T16:17:01.153 に答える
0

そのCREATETABLEステートメントが正しいことを確認しますか？PK定義で[チャネル]を使用していますが、それが列として表示されていません。[ユーザー]のことですか。

どこかにユーザーテーブルがありますか？その場合は、整数値でキーを設定し、UserではなくUserIDをコメントテーブルに配置することで、多くのオーバーヘッドを節約できます。

CommentIDでPKを実行してから、[UserID、CommentID]に非クラスター化インデックスを追加します。これにより、WHERE句にUserID値を含めることなく、IDによるコメント（削除など）にすぐにアクセスできます。また、ユーザーのコメントにすばやくアクセスできます。しかし、私はあなたが期待するサイズのテーブルで作業する傾向はありません。

于 2010-10-21T16:55:43.297 に答える
0

ユーザー名は変更される可能性があり、後でカスケード更新の問題が発生する可能性があるため、PK ではユーザー名を使用しません。また、これら 2 つを PK に連結すると、FK として他のテーブルに渡す必要がある大きな (r) PK が作成されます。クエリの速度のために 1 つの大きなキーに寄与するテーブルのすべての PK が必要になることがわかっている場合を除き、FK として表示される PK をできるだけ小さく保つようにしています。コメントIDは問題ないはずです。コメント ID とユーザー名ですばやく検索するには、追加のインデックスを作成する必要がある場合があります。挿入/更新またはクエリをさらに行う予定はありますか? クエリが集中している場合、インデックスは問題になりません。

于 2010-10-21T16:47:04.950 に答える
0

経験則として、常に最も狭い PK を選択します。次に、パフォーマンスを向上させるために、varchar の代わりに整数ベースの User_id を使用し、両方の列にインデックスを追加することができます。

最善のアプローチはユーザーの数によって異なります。ユーザーが数人しかいない場合は、commet_id user_id pk の方が適している可能性があります (さらに、ユーザーごとのパーティション分割がオプションになります)。一方、ユーザー数が多い場合、組み合わせた Pk は役に立たなくなります。

于 2010-10-21T17:33:24.000 に答える
0

私の最初のアプローチは、CommentID だけを PK にすることです。おそらく降順で、選択時に並べ替えを行う必要はありません。次に、UserID にインデックスを付けます。

連結キーを使用する場合は、CommentID を desc に切り替えることを検討してください。

于 2010-10-21T17:45:32.910 に答える