sql - 与非集群相比，外键列上的聚集索引是否可以提高联接性能？

Question

在许多地方，建议在使用BETWEEN语句选择行范围时更好地利用聚集索引。我猜想当我选择使用外键字段进行联接以使用此聚簇索引时，我猜想，由于行的范围被选择，即使它们都具有相同的聚簇键值且未使用BETWEEN时，聚簇也应会有所帮助。

考虑到我只关心一个带有join的选择，而不关心其他任何事情，我的猜测是否错了？

Answer 1

绝对讨论这种类型的问题不是很有用。

总是一个个案的情况!

本质上，通过聚集索引的访问可节省一个间接句点。

假设在JOIN中使用的键是聚集索引的键，那么在单次读取中[无论是来自索引查找还是来自扫描或部分扫描，都没有关系]，您将获得整行(记录)。

聚集索引的一个问题是，每个表只能获得一个索引。因此，您需要明智地使用它。实际上，在某些情况下，由于INSERT开销和碎片(取决于 key 和新 key 的顺序等)，根本不使用任何聚集索引甚至更为明智。

有时，人们可以获得与oj​​it_a相同的聚集索引的好处，即covering index，即具有所需键序列的索引，然后是我们感兴趣的列值。就像聚集索引一样，覆盖索引不需要到基础表的间接访问。实际上，覆盖索引可能比聚簇索引稍微有效，因为它较小。
但是，就像聚簇索引一样，除了存储开销之外，在INSERT(和DELETE或UPDATE)查询期间，还有与任何额外索引相关的性能成本。

并且，是的，如其他答案所示，用于聚集索引的 key 的“外键性”与索引的性能完全无关。 FK是旨在简化数据库完整性维护的约束，但是基础字段(列)与表中的任何其他字段一样。

要明智地决定索引结构，需要

了解各种索引类型(和堆)的工作方式
(而且，顺便说一句，这在SQL实现之间有所不同)

可以很好地掌握数据库的统计信息:
哪些是大表，哪些是关系，什么是关系的平均/最大基数，什么是数据库的典型增长率等？

对将要使用/查询数据库的方式有很好的了解/查询

然后并且只有那时，人们才能对有兴趣(或缺乏兴趣)做出有根据的猜测，以得到给定的聚集索引。