我们有许多表,其中我们有复合键与多个条目。在某些情况下,多达六个值,组成一个表的主键不是超大,也许几千个条目,并没有访问非常频繁。
一个更好的解决方案是使用一个主键,它是一个自动递增的ID字段,为了确保现在用作主键的六个不同字段的组合是唯一的,您可以创建一个具有唯一约束的索引。性能可能不是很好,但代码复杂性会大大降低。
有人告诉我,将主键设置得如此复杂是必要的,因为主键是表上唯一的聚集索引,这样做可以提高性能。我可以理解这会有什么帮助,但性能提高有那么大吗?这似乎是一个过早的优化。
使用复合主键是常见的做法吗?我知道,如果您有一个非常大的表,其中有数千个条目,并且经常被命中,那么即使是很小的性能增强也值得增加我所看到的复杂性。
如果主键由可以更新/更改的值组成,这似乎也是自找麻烦。如果其他表引用它,这难道不会导致问题吗?
这主要是为了增加新的表,因为改变现有表的结构可能是一个太大的变化,他们无法接受。但我想知道我是否越界,然后才试图反对这种做法。
1条答案
按热度按时间fumotvh31#
通常使用许多列来形成主键是我在数据库审计中经常发现的最糟糕的做法。事实上,它在50年代的层次数据库模型中使用过...由于性能差而被放弃!
数据库关系模型认为键可以是任何列或列组,但数据库Maven和实践者都证明,为了确保可伸缩性,最好的方法是只有一个列的键,数据类型为:
假设所有这些注意事项的唯一方法是使PRIMARY KEY具有自动递增的数据类型,如IDENTITY或SEQUENCE。
每一个其他的数据类型或方法都有一些额外的开销或性能很差。
在使用复合列的PK的情况下,优化程序的统计信息只对键的第一列准确。多列组合的统计信息不存在任何准确的方式(除了在严格相等的情况下键的所有值的完整集合并且当然这总是等于1),计算相关基数。在这两种情况下,执行计划的质量都很差,有时甚至是灾难性的...
对于MS SQL Server,聚集索引是PK的最佳选择,前提是严格应用我编写的所有规范。