我有一个表格,用于存储用户用户的评论。我将有1亿条评论。
我可以通过两种方式创建它:
选项1:用户名和评论ID为PK。这样,所有注释都按用户名和注释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条评论不再是因为用户未存储的数据(即未按用户排序)。所以我必须创建其他索引来提高查询性能。
哪种方式是最好的方法? 插入和删除怎么样?允许这些操作。但经常阅读。
用户无法修改他们的评论。
我用1.1M行测试了两个表。结果如下:
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
因此,使用com_id作为PK的表仅为2索引使用36MB额外磁盘空间 使用SEEK在两个表上选择顶部查询,但使用com_id作为PK的表更慢 但是当我把com_id当作PK
时插入会稍快一点有任何意见吗?
答案 0 :(得分:2)
我会使用Comment ID作为表的主键。如果您要使用注释ID和用户名进行大量查询,那么在这些字段上添加索引可能更简单。
答案 1 :(得分:0)
我不会在PK中使用用户名,因为它可能会更改,稍后会创建级联更新问题。 此外,将这两者连接到PK中会创建一个大(r)PK,可能必须作为FK传递给其他表。我尽量保持PK显示为尽可能小的FK,除非我知道我会想要一个大键中的贡献表的所有PK以提高查询速度。 评论ID应该没问题。 您可能需要创建一个附加索引,以便快速搜索注释ID和用户名。 你会做更多的插入/更新或查询吗?如果查询密集,则索引不是问题。
答案 2 :(得分:0)
您确定您的CREATE TABLE语句正确吗?你在PK定义中使用[Channel],我不认为它是一个列。你的意思是[用户]。
你在某个地方有用户表吗?如果是这样,您可以通过在整数值上键入并将UserID放入评论表而不是用户来节省大量开销。
我会在CommentID上PK,然后在[UserID,CommentID]上添加非聚集索引。这使您可以通过ID(删除等)立即访问注释,而无需在WHERE子句中涉及UserID值;它可以快速访问用户的评论。但是,我并不倾向于使用您预期的尺寸表。
答案 3 :(得分:0)
根据经验,总是选择最窄的PK。然后,为了提高性能,您可能希望使用基于整数的User_id而不是varchar,并为这两列添加索引。
最佳方法取决于用户数量,如果只有少数用户,则commet_id user_id pk可能更好(另外,用户可以选择分区);另一方面,如果用户数量很高,合并的Pk将无用。
答案 4 :(得分:0)
我最初的方法是单独将CommentID设为PK,可能按降序排列,这样您就不必对select进行任何重新排序。然后在UserID上放一个索引。
如果使用连锁密钥,请考虑将CommentID切换为desc。