SQL Server 中的 FK 验证是否始终使用 sys.foreign_keys 中指定的索引?

发布于 2024-12-03 09:07:48 字数 1362 浏览 0 评论 0原文

我找不到任何讨论有多个可能的索引可用于备份 FK 约束的情况。

从下面的测试看来,在 FK 创建时,FK 会绑定到特定索引,并且无论稍后是否添加新的更好的索引,这都将始终用于验证 FK 约束。

任何人都可以指出任何资源来证实或否认这一点吗?

CREATE TABLE T1(
    T1_Id INT IDENTITY(1,1) PRIMARY KEY CLUSTERED  NOT NULL,
    Filler CHAR(4000) NULL,
) 

INSERT INTO T1 VALUES ('');


CREATE TABLE T2(
    T2_Id INT IDENTITY(1,1) PRIMARY KEY NOT NULL,
    T1_Id INT NOT NULL CONSTRAINT FK REFERENCES T1 (T1_Id), 
    Filler CHAR(4000) NULL,
)

/*Execution Plan uses clustered index - There is no NCI*/ 
INSERT INTO T2 VALUES (1,1) 

ALTER TABLE T1 ADD CONSTRAINT
    UQ_T1 UNIQUE NONCLUSTERED(T1_Id) 

/*Execution Plan still use clustered index even after NCI created*/    
INSERT INTO T2 VALUES (1,1) 

SELECT fk.name,
       ix.name,
       ix.type_desc
FROM sys.foreign_keys fk
JOIN sys.indexes ix ON ix.object_id = fk.referenced_object_id
AND ix.index_id = fk.key_index_id
WHERE fk.name = 'FK'


ALTER TABLE T2 DROP CONSTRAINT FK
ALTER TABLE T2  WITH CHECK ADD  CONSTRAINT FK FOREIGN KEY(T1_Id)
REFERENCES T1 (T1_Id)    

/*Now Execution Plan now uses non clustered index*/    
INSERT INTO T2 VALUES (1,1)    

SELECT fk.name,
       ix.name,
       ix.type_desc
FROM sys.foreign_keys fk
JOIN sys.indexes ix ON ix.object_id = fk.referenced_object_id
AND ix.index_id = fk.key_index_id
WHERE fk.name = 'FK'

DROP TABLE T2
DROP TABLE T1

I can't find anything discussing the case where there are multiple possible indexes that could be used to backup a FK constraint.

It seems from the test below that at FK creation time the FK gets bound to a specific index and this will always be used to validate the FK constraint irrespective of whether a new better index gets added later.

Can any one point to any resources confirming or denying this?

CREATE TABLE T1(
    T1_Id INT IDENTITY(1,1) PRIMARY KEY CLUSTERED  NOT NULL,
    Filler CHAR(4000) NULL,
) 

INSERT INTO T1 VALUES ('');


CREATE TABLE T2(
    T2_Id INT IDENTITY(1,1) PRIMARY KEY NOT NULL,
    T1_Id INT NOT NULL CONSTRAINT FK REFERENCES T1 (T1_Id), 
    Filler CHAR(4000) NULL,
)

/*Execution Plan uses clustered index - There is no NCI*/ 
INSERT INTO T2 VALUES (1,1) 

ALTER TABLE T1 ADD CONSTRAINT
    UQ_T1 UNIQUE NONCLUSTERED(T1_Id) 

/*Execution Plan still use clustered index even after NCI created*/    
INSERT INTO T2 VALUES (1,1) 

SELECT fk.name,
       ix.name,
       ix.type_desc
FROM sys.foreign_keys fk
JOIN sys.indexes ix ON ix.object_id = fk.referenced_object_id
AND ix.index_id = fk.key_index_id
WHERE fk.name = 'FK'


ALTER TABLE T2 DROP CONSTRAINT FK
ALTER TABLE T2  WITH CHECK ADD  CONSTRAINT FK FOREIGN KEY(T1_Id)
REFERENCES T1 (T1_Id)    

/*Now Execution Plan now uses non clustered index*/    
INSERT INTO T2 VALUES (1,1)    

SELECT fk.name,
       ix.name,
       ix.type_desc
FROM sys.foreign_keys fk
JOIN sys.indexes ix ON ix.object_id = fk.referenced_object_id
AND ix.index_id = fk.key_index_id
WHERE fk.name = 'FK'

DROP TABLE T2
DROP TABLE T1

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

浮华 2024-12-10 09:07:48

马丁,我很抱歉这不是一个很好的答案,但既然你也让我很好奇,我做了一些挖掘。我可以分享的信息是:

在当前版本(包括 Denali)中,在这种情况下不太可能考虑替代方案。

Martin, I apologize that this isn't much of an answer, but since you made me curious as well, I did some digging. The information that I can share is:

It is unlikely in current versions, including Denali, that an alternative would ever be considered in this situation.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文