为什么有些 DBMS 中 fk 自动生成索引?

发布于 2024-11-15 06:53:50 字数 124 浏览 1 评论 0原文

我知道外键应该被索引,但我找不到原因,或者至少,为什么有些 DBMS 自动拥有它而其他 DBMS 没有。

有人可以帮助我澄清这一点和/或给出一些为 fks 创建/不创建索引的 DBMS 示例吗?

谢谢。

I know that foreign keys should be indexed, but I can't find the reason why or , at least, why do some DBMS have it automatically and others don't.

Could someone please help me to clarify this and/or give some examples of DBMS that do/don't create indexes for fks?

Thank you.

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

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

发布评论

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

评论(2

相思故 2024-11-22 06:53:50

对引用列的每次更新或删除都要求数据库检查所有引用列是否存在完整性违规。其中每项检查都需要检查引用列以查看它们是否正在使用即将更改或删除的值。

因此,验证 FK 的完整性需要对引用它的列进行大量查询。向这些列添加索引可以使完整性检查更快。如果引用列上没有索引,则更改引用列(或删除 FK 指向它的行)将需要对引用它的每个表进行表扫描。表扫描不是你的朋友,但 FK 肯定是。

Every update or delete on the referenced column requires the database to check all the referencing columns for integrity violations. Each of those checks requires checking the referencing columns to see if they're using the value that is about to be changed or deleted.

So validating the integrity of the FK requires a lot of queries on the columns that reference it. Adding indexes to those columns makes the integrity checking much quicker. If there weren't indexes on the referencing columns, then changing the referenced column (or deleting a row that has FKs pointing to it) would require doing table scans on every table that that references it. Table scans are not your friend but FKs certainly are.

陌上芳菲 2024-11-22 06:53:50

由于外键代表数据之间的关系,并且预计在选择结果时会被利用,因此对它们进行索引以提高操作速度是有意义的。

它们是否由数据库引擎自动索引实际上只是一个实施决策。

Since foreign keys represent relationships between data and are expected to be leveraged when selecting results, it makes sense to index them to improve the speed of the operation.

Whether or not they are automagically indexed by your db engine is really just an implementation decision.

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