5列以上的主键对大型（1亿+）表不利吗？

我正在阅读有关一些现实生活中的数据库问题的信息，一个项目有一个拥有1亿行的表格，其中有5列作为主要表格。我认为这很糟糕，但是有人可以告诉我原因吗？

该表有点像微型汇总/汇总表，因此5列是（天，market_id，product_id ...）。起初，我认为5列主键并不理想，但我想多了一点，我真的无法提出一个很好的理由来说明它不好。

这是在半夜与公司一半的工程师进行的讨论中。一位高级工程师同意，有人刚刚提到这是一个糟糕的设计，但没人真正了解原因。因此尝试自己研究问题！

非常复杂的主键存在性能问题。而且它可能无法像简单的主键一样防止重复。

但是，有一种设计模式经常产生具有由六个左右组件组成的主键的表。这是星型架构事实表。如果星型模式的事实表具有六个维度，则主键将具有六个组件。我从未见过没有声明主键的事实表，尽管ETL流程仍必须非常仔细地编写，但我认为这样做值得开销。

一些报表数据库模仿星型模式，即使它不是明确设计的。

对于事实表而言，1亿多行并不是太大，尤其是对于当今的大数据而言。

该表是汇总/汇总表。

那不仅好，而且是“正确的”。

由于它以开头，因此闻起来像是摘要表day。

你有一些二级索引吗？请记住，如果您使用的是InnoDB，则其余的PRIMARY KEY列将添加到二级索引的末尾。同样，这不一定是问题。

1亿行对于汇总来说是很多的。听起来表格太细了。也就是说，也许相反，如果（date，a，b，c，d）您应该有4个具有PK的汇总，例如（date，a，b，c），（date，b，c，d），（date，c， d，a），（date，d，a，b）（或一些合适的组合）。我这样做时，每个行可能只有1000万行，从而使报表速度更快，同时报表具有几乎相同的灵活性。

或者也许切换到（week，a，b，c，d），导致可能只有1400万行。（可能更多。）

使用PARTITION促进修剪 - 高速提取 - 数据仓库提示 - 汇总表。这些总结了我在几个DW项目中开发的许多技术。可以推断，每个项目都是不同的。摘要表的“典型”数量（以我的经验）是3-7。摘要的目标是10个事实行-> 1个摘要行。（这可能是“中位数”。）在极少数情况下，我汇总了“摘要”表。在另一种罕见的情况下，我对摘要表进行了分区以达到良好的效果；通常，摘要表足够小，因此它们足够快，可以从UI直接访问。

好吧，实际上拥有5列以上的PK本身不一定是不好的。

一旦PK也是聚簇索引，那就变得很糟糕，因为PK会被视为行标识符，因此会被添加到NC索引的每一行中。这将大大增加所需的空间。

一旦您实际使用了另一个FK的PK，那也将很不好，因为您必须在当前表以及从中引用的那五个表中都包含所有5+列的数据。它将再次增加很多存储空间！

从性能角度来看，一旦将PK用作索引（将其单独放置在表中或与FK结合使用）将是很糟糕的，因为包含5个以上列的更大的PK-Key将占用更多空间，因此条目将更少放入页面中，因此需要阅读更多页面来分析索引。

就是说-无论如何，总会有一个确实这样做的充分理由，例如事实表。因此，最佳答案实际上是在大多数情况下：取决于情况！

问候丹尼斯

在15多年的时间里，我不需要这样的钥匙，有时会看到它，而这只会引起麻烦。麻烦很多。首先，主键用于保持数据完整性，并且应该具有协同作用。他们对现实世界不应有任何约束力。为什么呢 一旦现实世界发生了变化，那么您的主键肯定会消失，您必须对其进行更新以及所有相关信息。

想象一下，您需要在其他表/数据库/服务中记住此ker，而不是一个字段，而需要复制多个字段，而您忘记了复制其中一些字段。相反，必须提供系统主键，它只是一个数据。我没有提到索引的唯一性，这可能是另一个巨大的话题需要讨论。

因此，简短的摘要，句法主键（自动递增，guid，..）易于维护，复制，...

因此，我考虑了句法主键，以及您提到的5列的另一个键。

最后，如果表仅是聚合的，并且永远不会有人需要按键引用行（但是世界发生了变化，请相信我，它将（至少对我来说它将永久更改）），我可能会像原样保留它（主要键（包含五行）），但如果以前曾经遇到过，总是会造成很多麻烦。所以我告诉你。