如何分配FK指数？

Question

我是一名普通的“将成为DBA”级别的开发人员。我一直在处理一些有几百万条记录的数据库。很多事情都是在数据库及其克隆之间导入数据，然后在Web应用程序环境中使用该克隆。

嗯，我已经知道自动保留PK索引，因此它有助于加速数据访问。现在，从这个讨论中我得出，如果我在我的SQL查询中使用JOIN，那么我就会使用FK并对其进行索引以使JOIN操作高效。

例如 ，我有一个表OrgMaster（包含所有Org记录），然后我有一个BookingMaster表（包含所有预订记录）。现在，OrgMaster.Id被“引用”为BookingMaster.OrgId。所以，我有一个关于OrgId-to-Id关系的FK，并且为了更好地执行这两个表之间的任何JOIN操作而对其进行“索引”...我是否正确地理解了它？

以上所有 - 以额外的空间和时间开销为代价（在FK表中插入记录时）。

我要求您提供一个要考虑的要点列表，例如：

• FK-index是否会占用太多空间\时间，因为该表会增加数百万条记录？
• 在这种情况下，是否值得“每次”使用FK索引？

• 在什么情况下shud我不申请FK或索引它或不做它们（当然我可以从应用程序处理很多）

• 加速JOIN或其他如此耗时的查询还有什么其他技巧？

谢谢。

Answer 1

如果要利用参照完整性约束，则必须使用外键。

Answer 2

你的问题：
随着桌面增长几百万条记录，FK-index会占用太多空间/时间吗？

不用担心，在这里，至少不会担心“随着表格的增长”。对于添加的记录数量，空间和时间要求将线性。（从技术上来说，如果跨越在树中引入额外级别的边界，但通常是有数百万条记录的数据库，树的深度很容易被认为是

在这种情况下，每次“FK指数”都值得吗？

通常是，但确实是个案情况。有人认为，考虑包括附加列的索引，而不是普通的FK索引，可以用于搜索和覆盖选择列表的[部分]。再次决定这样的替代（或附加索引）是个案，抱歉;-) ......

在什么情况下我不应该申请FK或将其编入索引或不执行任何操作（当然我可以从应用程序处理很多）

当然所有这些情况都排除了dbms本身本身支持参照完整性的重要情况（这种完整性也可以在数据库中插入和删除行的应用程序/进程级别进行管理）< / p>

• 大多数[时间或资源]关键查询意味着表上的其他过滤器的情况，并且SQL可以通过检查表中的值（或覆盖索引，特别是一个）来解析JOIN对于这些其他过滤器产生的可能结果的[小]子集，FK不是列出的第一列）。
• 表表格相对较小的情况（查找表等），因为SQL经常决定它们的扫描策略以及缓存时的表格。但是，它们很小，而且通常是相对静态的，因此额外索引的成本不会成为问题......
• 可能还有一些案例......

加速JOIN或其他如此耗时的查询还有什么其他技巧？

当涉及到移动数据时，例如当添加大量数据时等。删除索引（或其中一些）通常是一种有价值的策略，执行CUD（INSERT / UPDATE / DELETE） ）操作，然后重新创建索引。当然，如果在更新期间同时搜索数据库等，这并不总是可行的。

同时注意与索引关联的FILL_FACTOR，作为这些的明智选择，至少在索引的预定维护之间保持索引碎片化至少（以消耗为代价，从更多空间开始）

Answer 3

如果您已将数据规范化，那么您应该使用外键约束;这是保证数据无效的唯一实用方法。

是否应该在该外键上创建索引稍微复杂一些。在所有RDBMS中，外键的索引创建不是自动的。与任何其他索引一样，它会交换空间和插入时间以实现更快的读取（可能特别明显，因为JOIN操作往往是数据库中较慢的操作之一）。您还需要考虑FK列是否会被另一个索引覆盖，并且可能不需要自己的索引。

Answer 4

我不是专家，但我可能会对您的问题清单提供一些共同意见：

• FK-index增加了一点空间/时间，但仍然值得它
• 是的，值得的
• FK附带索引
• FK适合加入;其他查询是完全不同的故事。

---

对于大多数查找，不值得预先优化，但要等到观察性能问题，然后：

1. 精确测量
2. 进行更改
3. 再次测量，比较
4. 如果没有获得或不值得麻烦，请放弃更改

---

另请注意，索引不一定只涵盖一列，而是多列。 这需要更多的推理，关于使用哪些列以及使用什么顺序。 这些问题对于绩效至关重要。