SQL Server 主键设计

Posted 2023-05-08

【中文标题】SQL Server 主键设计

【英文标题】：SQL Server Primary Key Design

【发布时间】：2016-01-25 12:53:47

【问题描述】：

我目前正在研究可用于重新设计数据库架构的选项。不幸的是，最初设计数据库的人使用 GUID 数据类型作为主键和聚集索引（我很清楚这会导致的问题，现在在数据库的性能中很明显）。

阅读了几篇文章后，我的意图是在每个表中使用自动递增的整数标识列 - 这些将用于形成聚集索引。

我的问题是，使用此列作为主键有什么危险吗？

目前，我已经进行了一些测试，其中我将标识列组合用于聚集索引，将 GUID 组合用于主键，并且性能得到了显着提升。但是，我的理解是，如果我也使用较小的标识列作为我的主键，将会有更多的性能改进。我主要关心的是保持与镜像等相关的身份值的完整性——但也许我什么都不担心。

我们计划最终将数据库托管在 Azure 上

谢谢

【问题讨论】：

***.com/questions/11938044/…

【参考方案1】：

使用标识整数主键，因为它们更容易索引、扫描更快并且使用更少的索引存储。

为了您的镜像问题，保留一个 GUID 类型的 集成键 列 - 只是不要将其作为主键列。

【讨论】：

感谢乔丹的回复。我应该对镜像有任何顾虑吗？谢谢。

这取决于你如何镜像以及为什么。如果您进行磁盘复制或使用维护外键的工具，那么您就可以了。如果您通过插入迁移数据来重建数据库，则身份键将更改（重新开始），因此您将失去外键完整性。例如，假设您有一个在本地、断开连接的数据库中工作的应用程序。然后，您希望在远程数据库联机时将记录同步到远程数据库。拥有集成密钥会有所帮助，因为密钥不会再水化。否则，您无需担心。

据我了解，镜像将在 Azure 中配置，因此根据您的解释，我不应该担心任何事情。谢谢你的帮助。非常感谢。

【参考方案2】：

使用整数 IDENTITY PK。唯一的问题是，如果您没有创建适当的 FK，那么您最终可能会在相关表中出现“孤立”行。

还要记住，在要添加大量行的表（例如日志表）中，即使任何时候的行数很少（由于任何叛国罪的删除），IDENTITY 也会不断增加。在繁忙的表中，这最终可能会达到 int 的限制，并且会引起大惊小怪。在设计过程中应该可以预见到这一点，如果发生这种情况，则使用 bigint（64 位）而不是 int（32 位）。当我使用 bigint 时，我从未见过性能下降。请注意，超过 210 亿行必须有很多行。