Question

说我有 - 客户表，PK是ClientId
- 产品表，PK是ProductId
我需要为少数客户存储他们的内部产品参考，因此我创建了一个Client-Product表：

CREATE TABLE [dbo].[Product-Client](
    [IdProduct] [varchar](15) NOT NULL,
    [IdClient] [varchar](10) NOT NULL,
    [RefClient] [varchar](20) NOT NULL,       --client's internal product Id
 CONSTRAINT [aaaaaArticles-Clients_PK] PRIMARY KEY CLUSTERED   -- sure ???
(
    [IdClient] ASC,
    [IdProduct] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]

当然，我还会添加2个FOREIGN KEY约束，以确保ProductId存在且客户端存在。
我想要一个关于ProductId + ClientId的唯一索引我想在ClientId + RefClient上有一个唯一的索引知道这些客户端引用是非常静态的，所以它们很少更新，但经常阅读，我的问题是：

什么是理想的PK？
哪个索引应该是CLUSTERED一个？

编辑
对于问题1，当然有3种可能的答案：
a）ClientId + ProductId（无论如何都必须创建唯一索引）
b）ClientId + RefClient（无论如何都必须创建一个唯一的索引）
c）代理密钥

Answer 1

问题1的答案，我认为，主键应该是ClientId和ProductId的组合。这向人类表明该表包含与此组合相关的数据，而RefClient列包含数据。

在密钥中首先放入哪一个可以在某种程度上取决于用例。在语义上，首先使用ClientId是有意义的，因为（在我看来），该表包含主要与客户端关联的数据。但是从微优化，从其的角度来看，每纳秒一秒的性能压缩，答案可能取决于哪一列将有更多的数据变化。如果每个客户端值都会有一些不同的ClientId值，但会有很多ProductId个值，那么首先放置ProductId可能会有一些小的收获。

关于问题2，答案是它取决于用例，就像@swe写的那样。

如果我们认为该表几乎是静态的，那么我的猜测是主键ClientId + ProductId上的聚簇索引是理想的。

这是基于one client searches for many consecutive products比we want all clients with a specific id for this product更常见的用例的假设。这意味着可以在同一个数据页上找到表中的几行数据，从而减少IO（从光盘读取）。

总而言之，我认为语义应该是指导你决定的东西。试图从中挤出最终的性能似乎非常像过早的优化。因此，我建议您使用ClientId + ProductId作为主键和聚簇索引。

Answer 2

主键必须是唯一的。它与磁盘上的存储无关，BUT由SQL-Server-Management-Studio用作默认聚簇索引。理想的PK是每种情况下最小值的组合。

聚集索引应该建立在最常见的query-where-clause上。

但是有很多其他要考虑的问题，如果你真的想要最好的答案，你必须提供更多细节，包括但不限于：

您的桌子多久和平写一次，值的变化频率，您多久发送一次查询......

Answer 3

关于如何选择最佳指数的主题有很多书。简而言之，这取决于您将如何访问数据。

choosing the most suitable clustered index上还有明确定义的标准。如果您可以预测将访问该表的查询类型，您可以选择一个并以最有效的顺序排列其列。

从SQL Server 2005开始，有一个内置的索引建议功能，您可以使用它来改进索引。查看this reference，开始。此外，您可以在互联网上找到大量使用此功能的现成脚本。但是，与所有自动化建议一样，不应盲目追踪 - 您必须了解所创建的每个索引的优缺点。

简而言之，此处没有人可以预测最适合您特定类型工作负载的指数。但是，在很长一段时间内收集的实际查询统计数据支持的缺失索引建议可能是下一个最好的事情。

主键＆amp;聚集索引

3 个答案: