我是在 sql-server 和 .Net 下开发的某个项目的开发人员，他们不使用表之间的物理关系，而是使用逻辑关系“逻辑外键”。
我问他们这样做的原因是什么，他们说“这样更优化”。
我真正想知道的是，它真的更优化还是只是一个神话？
【问题讨论】：
标签： sql-server sql-server-2005 optimization relational-database
当涉及到从数据库中读取时，是否定义了外键并不会涉及到它。拥有外键和读取性能之间没有关系。
影响性能的因素是表的存储方式、在它们上定义的索引以及存储的统计信息（仅举几例）。
这是在数据库中没有参照完整性的一个不好的理由（特别是因为它可能很容易测试）。
假设“逻辑外键”只是引用另一个表中的键的值，它们之间没有物理链接constraints，我可以告诉你物理链接的好处是什么。
首先，“物理”外键是一个约束，它强制两个值之间的引用完整性。因此，例如，如果您想使用另一个表中不存在的外键，您将收到错误消息。如果您尝试在另一个表中通过约束删除作为外键的键，也会发生同样的情况。
其次，可以说它更优化，因为您可以索引外键约束并从中受益，例如当您使用连接时。
【讨论】：
“真实”外键和“逻辑”外键之间实际上没有物理区别。它们都只是表中的列，不会影响表在磁盘上的存储方式。当我第一次学习时，这实际上也让我感到惊讶。
唯一的区别是当你有一个“真正的”外键时，每当对表运行删除、更新或插入语句时，数据库服务器都必须检查该值是否被更新为合法值。如果您查看更新、插入、删除或合并语句的执行计划，您实际上会发现它必须扫描或查找所有具有外键的表。
如果有很多外键或没有有用的索引，这可能会产生相当大的性能开销。
想象一下，您有一张公司表，然后还有一张员工表。您的员工表可能会有一个名为 companyId 的列。
当你运行时：
delete from Companies where companyId = 123;
数据库服务器需要确保该 companyId 没有任何员工。运行时也是如此：
insert into Employees (companyId, name) values (123, 'John');
数据库服务器需要搜索companys表以确保companyId 123存在。
是的只有“逻辑”外键更快。但是，它是以可能的数据损坏为代价的，并且可能会花费更多时间来查找错误和其他数据损坏源。值不值，就看你自己了。需要考虑的一件事是它不会影响只读查询。
编辑 正如 Martin Smith 所指出的并且我已经遗漏了，在某些情况下外键会更快。如果在具有外键的表上存在内部连接，并且第二个表没有引用任何列，则查询不必命中第二个表，因为它可以信任外键。
【讨论】：