sql - 复合主键/聚集索引、碎片、性能

Question

经过 20 年的专业发展，我仍然发现自己对数据库性能的某些方面一无所知。这是那些时代之一。这里和其他地方有数以千计的关于表和索引碎片及其对性能影响的问题。我知道基本的注意事项，但有时似乎没有“好的”答案。这是我的问题，我经常遇到它:

表只是用来存储定义一对多关系的id对，我们以 friend 为例。 Friends 表只包含personId (int), friendId (int)。每一对当然都是独一无二的。 (因此，但可能与问题无关，每个关系的逆对也存在。)所以数据的一个非常小的样本将是:

1001, 1011
1001, 1012
1001, 1013
1011, 1001
1012, 1001
1013, 1001
etc...

人 1001 有 3 个 friend ，当然每个 friend 都有人 1001 作为 friend ，等等。这张表可能有数百万甚至数亿的关系(行)，任何给定的人都会附近可能有数百个 friend 。并且它们会被频繁地插入和更新(实际上在这种情况下，一些现有的被删除，新的被添加，没有实际的行更新)并且没有特定的顺序。对于任何给定的插入批处理，它们可以按 personId、friendId 排序，但除此之外，随着时间的推移，大部分插入将是无序的。

此表的用途是查询给定人的所有 friend ，或内部连接到人的查询以分组和聚合与每个人的 friend 相关的其他数据等，您期望的典型用途一对多关系表。查询性能可能比插入性能更重要，但两者都很重要，因为两者都经常发生。示例查询:

SELECT p.Name FROM Friends f
INNER JOIN People p ON f.friendId = p.id
WHERE f.personId = @personId

以前想都没想就给表一个personId,friendId的复合主键，在SQL Server中默认创建成聚簇索引，就搞定了用它。但我以前从未处理过如此庞大且对性能至关重要的数据，所以我质疑这个决定。我看不出有什么方法可以以不会导致大量和频繁碎片化的方式构建这样的表。我的问题是:

1. 是否有更好的方法来构建这些数据？

2. 考虑到聚簇索引的两个 int 列代表表中的唯一数据，碎片是否可能像我假设的那样糟糕，如果是这样，这些条件下的碎片是否会导致严重的后果如我所料，性能受到影响？

(除非 RDBMS 中有一些我不熟悉的完全不同的概念，否则我假设第一个问题的答案是否定的。所以这主要是第二个问题我希望有人有良好的经验基础回答。顺便说一句，如果有区别的话，数据库是 SQL Azure。)

感谢你们中的那些 DBA 大师，他们提供了一些见解!

Answer 1

您只需要包括两个字段的聚簇索引。无论是否聚集，索引都是有序数据。如果您创建非聚集索引，您的数据将加倍，并且每个插入操作都需要加倍的资源，因为它将在堆(或 row_id 聚集索引)和非聚集索引中插入数据。但是查找操作将只使用非聚集索引，因为所有需要的数据都包含在其中。

所以制作聚簇索引并快乐:)