这两种定义外键的方式不同吗？答案

【问题标题】：Are these two ways of defining foreign keys different?这两种定义外键的方式不同吗？
【发布时间】：2011-11-11 16:17:22
【问题描述】：

在下面的表定义中，这两个列定义有什么区别，还是说第二个只是创建了一个自动命名的外键索引？

CREATE TABLE dbo.Employee
(
    dept_id     int  NOT NULL  
        CONSTRAINT fk_employee_deptid FOREIGN KEY REFERENCES Department(dept_id),
    empType_id  int  NOT NULL  REFERENCES  EmployeeType(empType_id)
    /* ... other columns ... */
);

【问题讨论】：

请注意，虽然外键约束可以帮助优化器，但在技术上它不是索引。
在 SQL Server 中没有为外键自动生成没有索引 - 没有，从不。见：Does a foreign key automatically create an index?
感谢您对索引的澄清。

标签： sql sql-server foreign-keys create-table

【解决方案1】：

唯一的区别是第二个将被赋予一个系统生成的名称，该名称可能比您自己分配的名称更神秘。

如果有明确的可能性，列名也是可选的。

empType_id  int  NOT NULL  REFERENCES  EmployeeType

也可以。最终结果再次没有区别。 FK 声明的full grammar 是

[ CONSTRAINT constraint_name ] 
{      [ FOREIGN KEY ] 
        REFERENCES [ schema_name . ] referenced_table_name [ ( ref_column ) ] 
        [ ON DELETE { NO ACTION | CASCADE | SET NULL | SET DEFAULT } ] 
        [ ON UPDATE { NO ACTION | CASCADE | SET NULL | SET DEFAULT } ] 
        [ NOT FOR REPLICATION ] 
 }

可选项目括在方括号中。

【讨论】：

该死的，我不确定是怀疑我是在你的肩膀上阅读，还是你在阅读我的肩膀。 :-)

【解决方案2】：

唯一真正的区别是后者将获得系统定义的名称。前者是推荐的方法，虽然我承认我很懒，偶尔会使用后者。

如果您仔细观察，您会注意到的另一个区别是，如果您不自己指定名称，sys.foreign_keys.is_system_named 列将设置为 1。

【讨论】：

【解决方案3】：

在回答您的第二个问题时，两者都没有创建索引。如果您希望 FK 字段被索引（并且大多数时候您这样做），那么您需要在该字段上创建一个索引。

【讨论】：

感谢您的补充回答。