外键列上的聚簇索引是否会增加连接性能与非群集?

alp*_*pav 6 sql performance join foreign-keys clustered-index

在许多地方,建议在使用BETWEEN语句选择行范围时更好地利用聚簇索引.当我选择通过外键字段连接以使用此聚簇索引时,我想,该聚类应该也有帮助,因为即使它们都具有相同的聚簇键值并且未使用BETWEEN,也会选择行范围.

考虑到我只关心那个选择加入而没有别的,我猜错了吗?

mjv*_*mjv 9

在绝对中讨论这类问题并不是很有用.

这总是一个个案的情况!

实质上,通过聚簇索引进行访问可以节省一个间接期限.

假设JOIN中使用的密钥是聚集索引的密钥,在单个读取中[无论是从索引搜索还是从扫描或部分扫描,无关紧要],您将得到整行(记录).

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

有时,人们可以获得聚集索引的等效优势,使用覆盖索引,即具有所需键序列的索引,然后是我们感兴趣的列值.就像聚簇索引一样,覆盖索引不会要求间接到底层表.实际上,覆盖索引可能比聚集索引稍微更有效,因为它更小.
但是,就像聚簇索引一样,除了存储开销之外,在INSERT(和DELETE或UPDATE)查询期间还存在与任何额外索引相关的性能成本.

并且,是的,正如其他答案中所指出的,用于聚集索引的密钥的"外键密钥"对索引的性能完全没有影响.FK是旨在简化数据库完整性维护的约束,但是底层字段(列)与表中的任何其他字段一样.

一个人需要做出关于指数结构的明智决策

  • 了解各种索引类型(和堆)的工作方式
    (以及BTW,这在SQL实现之间有所不同)
  • 掌握数据库统计概况的良好形象:
    哪些是大表,哪些是关系,什么是关系的平均/最大基数,数据库的典型增长率是什么等等.
  • 对于将要使用/查询数据库的方式有很好的了解

然后,只有到那时,人们才能对有兴趣[或缺乏]有一个给定的聚集索引进行有根据的猜测.