主键仅作为主表上的复合

Question

我们的环境中有一张桌子。最近，人们发现通过对日期时间进行排序可以大大提高性能，dba想要成为主键。由于他无法保证日期时间的唯一性，因此他将曾经是主键的id添加到他的新复合键中。

因此，有一个主键作为datetime / id的表，并且聚集索引也是这样定义的。所有pk / fk关系仍然正确设置并存在于id期望的范例中。

一个不平衡的主键可能存在什么问题？

通过这种改变，性能得到了显着提升。

然而，在架构中，实际的＆＃34;主键＆＃34;是两列。什么可能出错？

Answer 1

不要那样做！使用这两个字段设置唯一索引。它不一定是主键。事实上，如果您希望原始密钥保持唯一，那么这是一个糟糕的主意。

Answer 2

编辑：这个答案是假设Sql Server。如果结果不是，那么我将删除我的答案。

您没有列出详细信息，因此我必须给出一个非常一般的答案。在我的研究中，我发现大多数人会推荐一个简短的主键/聚簇索引。

这里真正的关键是你的意思是提高了性能。这只是一个查询吗？换句话说，此更改是否对此数据的所有操作产生有益或至少无关紧要的性能影响？用户界面，所有报告等。或者这个劫掠彼得要付保罗？

如果这是一个报告数据库或数据仓库，其中大多数报告都是基于日期的，我可以看到为什么人们可能会建议设置聚簇索引，以使所有报告受益，或者最重要的报告

在任何其他情况下，我都可以考虑让非聚集索引提供几乎相同的级别或性能提升，而不会增加PK的大小，这在所有查找中使用（更多字节读取=性能更慢）占用数据页面上的更多空间。

编辑： 本文更好地解释了这个主题。

https://www.simple-talk.com/sql/learn-sql-server/effective-clustered-indexes/

Answer 3

您目前看到的性能优势（如果是正版）是由与主键关联的聚簇索引引起的，而不是主键本身。如果您对当前索引感到满意，但是关注唯一性，则应将唯一的datetime / id保留为聚簇索引，但将旧的唯一ID作为主键恢复。

这也解决了引用此主键的其他表需要创建可能不合适的datetime列来创建外键关系的问题。