SQL主键-复杂主键还是带串联的字符串?

您必须考虑更多因素:

• 数据访问的普遍模式,您打算如何访问表?
• 有多少非聚集索引?
• 更新频率
• 更新模式(顺序插入,随机)
• 删除模式

所有这些因素,特别是前两个因素,都应该促使您选择集群密钥。注意,主键和聚集键是不同的概念,经常混淆。阅读我的答案 Should I design a table with a primary key of varchar or int? 对于驱动群集键选择的条件进行更深入的讨论。

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

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

在性能方面,一个较短的、基于整数的主键是最好的。

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

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

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

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

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

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

这个决定取决于它的用途。如果您主要使用表来保存数据而不是检索数据,那么只需一个简单的键。如果您主要是在查询数据,而且主要是静态数据,而键值不会改变,那么您的索引策略需要将数据优化为将要使用的最频繁的查询。就我个人而言,我喜欢使用guid作为主键,使用int作为聚集索引。这样可以方便地导入数据。但是,这真的取决于你的需要。

您没有提到的变量的lot__;两列中的数据是否为__natural__,并且通过逻辑ID识别记录有好处,如果通过UI公开密钥会带来风险,那么性能有多重要(几十万行非常小)。

如果您不太挑剔,请选择自动编号路径以获得速度和简单性。还可以看看网站上关于 SQL primary key types . 这里有成堆的信息。

是ER模型还是量纲模型?在ER模型中,它们应该是独立的,不应该被代理。整个记录可以有一个单一的代理,以便在URL等中方便地引用。这可以是组合键或标识的所有部分的散列。

在维度模型中,它们也必须是独立的,并且都应该被代理。