数据库是否透明地使用外键？

Question

数据库引擎是透明地使用外键还是查询应该明确使用它们？

根据我的经验，除了保持密钥唯一性的约束以及密钥（单个或一组字段）是使搜索有效的关键这一事实外，表中没有明确的外键概念。

为了澄清这一点，这里有一个重要的例子：我有一个中间件（特别是我的案例中的ArcGIS），我可以控制后端数据库（所以我可以创建密钥，索引等。 ）我通常使用前端（这里是一个RESTful API）。中间件本身就是一个黑盒子，并提供有效的工具来利用底层DBMS的功能。所以我想要理解的是，如果我构建外键约束并使用查询，如果正常实现将转换为使用这些外键的查询，我应该看到性能改进吗？

通常是这种情况还是各种引擎以不同的方式做到这一点？ （我正在使用PostgresSQL）。

Answer 1

外键不能提高性能。他们在那里强制执行数据完整性。他们将降低插入/更新/删除的性能，但它们对查询没有任何影响。

某些DBMS会自动为外键字段添加索引，这可能是混淆来自的地方。 Postgres没有这样做;你需要自己创建索引。 （是的，数据库将透明地使用此索引。）

Answer 2

据我所知，数据库引擎需要特定的查询才能使用外键。您必须编写某种连接查询以从相关表中获取数据。

然而，一些数据访问框架通过提供从相关表访问数据的透明方式隐藏了从外键访问数据的复杂性，但我不确定这可能会在性能上提供很大的改进。

Answer 3

这完全取决于数据库引擎。

在PostgreSQL中，约束不会直接导致性能提升，只有索引会这样做。

  

CREATE INDEX是PostgreSQL语言扩展。 SQL标准中没有索引的规定。

但是，添加一些约束将自动为该列创建索引 - f.ex. UNIQUE＆amp; PRIMARY KEY约束在受影响的列上创建btree索引。

FOREIGN KEY约束在引用列上不会创建索引，但是：

  

外键必须引用作为主键或形成唯一约束的列。这意味着引用的列始终具有索引（主键或唯一约束下面的索引）;因此，检查引用行是否匹配将是有效的。由于引用表中的行的DELETE或引用列的UPDATE将需要扫描引用表以查找与旧值匹配的行，因此通常也应该对引用列建立索引。因为并不总是需要这个，并且有很多关于如何索引的选择，所以外键约束的声明不会自动在引用列上创建索引。