主页 / dba / 问题 / 274435
Accepted
David Clarke
Asked: 2020-08-27 15:55:24 +0800 CST

从主键中删除不必要列的含义

  • 772

我有一个数据库，其中定义了许多表，其中多个 UUID 列形成主键，而应该将它们定义为外键，例如

CREATE TABLE [dbo].[SomeTable](
    [SomeTableID] [uniqueidentifier] NOT NULL,
    [WorkEntryID] [uniqueidentifier] NOT NULL,
    [TimeEntryID] [uniqueidentifier] NOT NULL,
    [RateEntryID] [uniqueidentifier] NOT NULL,
    ...

 CONSTRAINT [PK_SomeTable] PRIMARY KEY CLUSTERED 
 (
    [SomeTableID] ASC,
    [WorkEntryID] ASC,
    [TimeEntryID] ASC,
    [RateEntryID] ASC
 )
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[SomeTable] ADD  CONSTRAINT [DF_SomeTable_SomeTableID]  DEFAULT (newsequentialid()) FOR [SomeTableID]
GO

附加列应该被定义为外键，并且在某些情况下已经被定义。我假设将附加列作为 PK 的一部分会影响性能吗？在重新定义表的 PK 以仅包含 PK 列之前，我应该注意什么？

sql-server primary-key

1 个回答

  1. Best Answer

    SQL Server 中理想的聚集索引满足以下条件：

    1. 独特的
    2. 永不改变
    3. 新值严格递增
    4. 狭窄
    5. 针对表的查询运行得更快，因为它们可以利用范围搜索或聚集索引的排序

    在生产中，您可能无法选择满足所有这些标准的聚集索引，这很好。你只能做你能做的最好的。四个 GUID 的聚集索引是不常见的选择。我假设它将满足前两个标准，但不满足其他三个标准。当前索引的一个性能影响是非聚集索引将占用额外的磁盘空间，因为它们每个都存储聚集索引的副本。这就是为什么聚集索引在理想情况下是狭窄的。

    根据此问题中提供的信息，将聚集索引更改为SomeTableID列可能会更好。我在这里做了一些假设，但您不太可能看到该切换导致的性能下降。

    这个答案解决了聚集索引而不是主键，因为聚集索引对性能很重要，这似乎是这个问题的重点。主键用于强制数据完整性和业务约束。在这种情况下，继续匹配聚集索引的列和主键应该没问题，除非有商业原因需要保留当前的主键列。

    • 2

相关问题