1

我有一张16列的表格。它将成为网络应用中最常用的表格,它将包含大约几百行。数据库是在sql server 2008上创建的。SQL主键 - 复杂的主或字符串串联?

我的问题是主键的选择。什么更快?我可以使用复杂的主键与两个bigint-s或我可以使用一个varchar值,但我需要连接它后?

+3

基于整数的主键速度更快,但它是否适合您的数据是另一个问题... – 2009-10-18 01:38:01

+0

你是什么意思“使用一个varchar值,但我需要连接它后? – Mark 2009-10-18 10:26:23

+0

这意味着如果我使用varchar作为主键,那么在我几乎每次使用它时都必须操作该值。这就告诉我,这是一个糟糕的设计...... – Siblja 2009-10-19 10:55:40

回答

5

还有更多的因素必须考虑:

  • 数据访问模式盛行,你怎么来访问表?
  • 多少个非聚集索引?
  • 频率更新
  • 模式的更新(顺序插入,随机)删除

所有这些因素,以及专门的前两个

  • 模式,应该推动您的聚集键的选择。请注意,主键和集群键是不同的概念,经常会混淆。请阅读我在Should I design a table with a primary key of varchar or int?上的回答,详细讨论推动聚类关键选择的标准。

    没有关于您的访问模式的任何信息,我可以非常简短而且简洁地回答,并且实际上是正确的:更窄的密钥总是更快(出于IO的原因)。但是,这种回应毫无价值。唯一能够让你的应用程序更快的方法是在查询执行计划中选择一个将被用于的密钥。

  • +0

    谢谢,如果我以前发现并阅读讨论,我不会问问题 :) – Siblja 2009-10-19 11:20:40

    1

    为什么不只是一个INT自动生成的主键? INT是32位的,所以它可以处理超过40亿条记录。

    CREATE TABLE Records (
        recordId INT NOT NULL PRIMARY KEY, 
        ... 
    ); 
    
    2

    不依赖任何基础值的主键(称为surrogate key)是一个不错的选择。这样,如果行更改,ID不必,并且任何引用它的表格(Foriegn Keys)都不需要更改。我会为主键列选择一个自动编号(即IDENTITY)列。

    就性能而言,较短的基于整数的主键最好。

    您仍然可以在多列上创建聚簇索引。

    0

    该决定依赖于它的使用。如果您正在使用该表来保存数据,而不是检索它,那么只需一个简单的键。如果您主要查询数据,并且它主要是静态数据,其中键值不会更改,则您的索引策略需要将数据优化为将使用的最频繁查询。就我个人而言,我喜欢使用GUID作为主键,而使用int作为聚集索引。这可以轻松导入数据。但是,这确实取决于你的需求。

    0

    你是什么意思更快?如果您需要更快搜索,则可以为任何列创建索引或创建全文搜索。主键只是确保你没有重复的记录。

    +0

    其实,主键更多地反映了你的领域模型和它的关系.... – 2009-10-18 01:54:06

    1

    如果此表上有外键关系,代理键可能是个好主意。使用代理将保存引用它的表,而不必复制其表中的所有列。

    另一个重要的考虑因素是您将在WHERE子句中使用的列的索引。如果你不这样做,你的表现会受到影响。确保您在主键之上添加适当的索引,以避免表扫描。

    0

    您未提及的变量的批次;无论两列中的数据是否是“自然的”,并且通过逻辑ID识别记录是有益的,如果通过UI公开密钥会带来风险,性能有多重要(几十万行非常小) 。

    如果你不是太挑剔,去速度和简单的自动编号路径。也请看看网站上关于SQL primary key types的所有帖子。这里有大量的信息。

    0

    它是ER模型还是维度模型?在ER模型中,它们应该是分开的,不应该被替代。整个记录可以有一个单一的代理以方便在URL中引用等。这可能是组合键或身份的所有部分的散列。

    在维度模型中,它们也必须是分开的,它们都应该被替代。