我在我的数据库中有几个表是父子关系。例如:非集群外键索引推荐
CREATE TABLE [dbo].[cntnr_header]
(
[cntnr_id] [dbo].[uid] NOT NULL,
CONSTRAINT [pk_cntnr_header] PRIMARY KEY CLUSTERED ([cntnr_id] ASC),
);
CREATE TABLE [dbo].[cntnr_content]
(
[cntnr_content_id] [dbo].[uid] NOT NULL,
[cntnr_id] [dbo].[uid] NOT NULL,
CONSTRAINT [pk_cntnr_content]
PRIMARY KEY CLUSTERED ([cntnr_content_id] ASC),
CONSTRAINT [fk_cntnr_content_cntnr_header]
FOREIGN KEY ([cntnr_id])
REFERENCES [dbo].[cntnr_header] ([cntnr_id]),
);
目前你可以看到有没有在表格cntnr_content
外键cntnr_id
的索引。我运行了调整向导,并且实际上看到它表示在cntnr_content
表上cntnr_content_id
和cntnr_id
之间添加了非聚集索引。我不太明白这一点,因为cntnr_content_id
已经是一个聚集索引。为什么会推荐这样的索引?
CREATE NONCLUSTERED INDEX [_dta_index_cntnr_content_7_821577965__K1_K2] ON [dbo].[cntnr_content]
(
[cntnr_content_id] ASC,
[cntnr_id] ASC
)WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
我认为我也许应该在这个表只是cntnr_id
添加非聚集索引。
这种情况下是否有推荐的做法?我是否应该总是添加一些像这样的关系的索引?
很多查询要么将这两个表连接在cntnr_id
上,要么通过指定cntnr_id
对cntnr_content
进行选择。这也是一个更新/删除繁重的表格。更新和删除总是在主键上完成(cntnr_content_id
)。
关于外键的索引通常很有用,但要谨慎使用诸如“总是”和“从不”等术语。在这种情况下,它很大程度上不取决于表本身的结构或它们之间的关系,而是如何查询数据。 –
@AaronBertrand我在底部添加了一些其他信息,通常描述如何查询此表,但我也很好奇为什么调整顾问会在这两列上建议非聚集索引。 –
好吧,所以如果你的问题是,“这种情况下的这个外键的索引是否有用?”答案是,“可能,是的。”你需要测试。如果问题是,“所有外键上的索引总是有用吗?”答案是不。 –